Menu

#308 make <graphic> available within <table> and ...

AMBER
closed-accepted
5
2012-04-17
2011-05-20
Matthias
No

... change the occurrence of the element <row> withing <table> to optional.

I'm referring to the following thread within the TEI-L: http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1105&L=TEI-L&P=19477

If one wants to represent a table as a graphic he or she needs to do the following, because <graphic> is not allowed and <row> is mandatory within <table>.

<figure type="table">
<graphic url="fileShowingTable.pgn"/>
</figure>

The markup above would also mean that the tables are illustrations although they are tables.

However, if someone wants to represent a formula as a graphic he can do this:

<formula>
<graphic url="fileWithFormulaicContents.png"/>
</formula>

In my opinion these two approaches of representing a content object as a graphic should be aligned.

Best regards, Matthias

Discussion

  • Lou Burnard

    Lou Burnard - 2011-11-01

    I think the reasoning (such as it is) behind the the status quo is that it's not hard to think of a formula as a non-decomposable single graphic, whereas thinking of something as a table does imply that it has some internal structure (rows or columns) --- or otherwise it's just a picture, and as such should be tagged as a <figure>. But I agree that the discrepancy looks odd.

     
  • Lou Burnard

    Lou Burnard - 2011-11-01
    • labels: --> TEI: New or Changed Element
    • milestone: --> 871209
     
  • Lou Burnard

    Lou Burnard - 2011-11-08
    • assigned_to: nobody --> kshawkin
    • milestone: 871209 --> 871208
    • status: open --> pending-accepted
     
  • Lou Burnard

    Lou Burnard - 2011-11-08

    Documentation should include possibility of <graphic> within <formula> or <table>
    Change content model of <table> to permit one or more <graphic>s
    Or use @facs,

     
  • Kevin Hawkins

    Kevin Hawkins - 2011-11-27

    Implemented in revision 9831. Per minutes of Paris Council meeting, Lou should verify that I did the content model correctly.

     
  • Lou Burnard

    Lou Burnard - 2011-12-01

    The proposed content model is OK, but removes the possibility of including either <head> or model.globals if you choose graphic as content. Also, it permits more than one model.graphicLike: but I am not sure what that would mean.

     
  • Martin Holmes

    Martin Holmes - 2011-12-01

    We already discussed the possibility that there might be more than one graphic, because a table might extend over several pages. That of course brings up the requirement for <pb/>, and possibly <cb/> as well.

    This is the relevant bit of the minutes:

    3305016: Make <graphic> available within <table> and <formula> . BB, KH: The current content model of <formula> allows text or graphics. It turns out that table has similar requirements: it may (need to) be represented by a graphic element. So the proposal is to extend the model of table to include <graphic> . The prose should be revised not only for table but also for <formula> to explain that this is allowed. LB pointed out that you could use @facs, but MH replied that you should be able to choose between doing things in the same way as is done with <formula> if you wish, or use @facs throughout if that is your encoding practice. MH also pointed out that there is a use-case for more than one graphic (tables printed over several pages), so it should be one or more graphics. Set to pending, accepted and green. Assigned to KH (with help from LB for the content model change) to implement.

     
  • Lou Burnard

    Lou Burnard - 2011-12-08

    I missed the point about multiple graphics. It still seems a very strange idea to me. If the motivation for having more than one graphic is simply the pagination of the table, why not represent each page as with <pb facs="..."/> ? Effectively we're treating <table> in the same way as <zone> where we also have this dual method of embedding a graphic or using @facs. In the <zone> case however, we say that multiple embedded graphics means something different: they are alternatives -- whereas here the images must be aggregated in some undefined way.

     
  • Martin Holmes

    Martin Holmes - 2011-12-08

    I guess the obvious reason for not using <pb/> is that the initial graphic in the table probably isn't coterminous with a page-start; a typical long table will begin in the middle of page 23 and continue onto page 24, for instance, so you'd want to include two graphics, but only the second would happen to coincide with a page-break. It seems needlessly complex to recommend something like this:

    <table>
    <graphic url="table_part_1.jpg"/>
    <pb facs="table_part_2.jpg"/>
    </table>

    I think in a case like this, I'd want to do:

    <table>
    <graphic url="table_part_1.jpg"/>
    <pb n="24/>
    <graphic url="table_part_2.jpg"/>
    </table>

     
  • Kevin Hawkins

    Kevin Hawkins - 2012-02-26

    Just realized I wasn't monitoring this ticket and was therefore missing this conversation.

    I agree with Martin that there is a use case for a table being composed of multiple images because the images were created by scanning a source document in which the table spans multiple pages.

    As for allowing a table and model.global inside a table that uses model.graphicLike, this is in fact what brought me back to this ticket. I agree that we should allow head to be used with model.graphicLike: after all, the graphic may only include the table proper but not its title. As for model.global, we will need this in order to do it the way Martin and I would like.

    So I propose further revising the content model to the following:

    <content>
    <group>
    <zeroOrMore>
    <choice>
    <ref name="model.headLike"/>
    <ref name="model.global"/>
    </choice>
    </zeroOrMore>
    <choice>
    <oneOrMore>
    <ref name="row"/>
    <zeroOrMore>
    <ref name="model.global"/>
    </zeroOrMore>
    </oneOrMore>
    <oneOrMore>
    <ref name="model.graphicLike"/>
    <zeroOrMore>
    <ref name="model.global"/>
    </zeroOrMore>
    </oneOrMore>
    </choice>
    </group>
    </content>

     
  • Kevin Hawkins

    Kevin Hawkins - 2012-03-25
    • milestone: 871208 --> AMBER
    • status: pending-accepted --> open-accepted
     
  • James Cummings

    James Cummings - 2012-04-15

    The proposed content model seems reasonable to me.

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2012-04-17

    latest content model duly implemented after Council F2F 2012-04-17

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2012-04-17
    • status: open-accepted --> closed-accepted