#98 graphic should allow desc child

AMBER
closed-fixed
Lou Burnard
3
2010-04-06
2009-06-25
James Cummings
No

There are many places where <graphic/> is allowed in which you might want the rendered version of that <graphic/> to contain a descriptive metadata about it the image in question. i.e. the information you might want to supply to an @html:alt attribute when rendering. Currently there is no good way I can see to do this? Certainly figDesc exists when describing figures, but nothing similar exists for <graphic/>

A use case for this is <graphic/> as a child of <char>, especially when you have multiple <graphic/>s at that point. e.g. you have the character as rendered by one font or another version of that font, or another font entirely.
<char xml:id="whatever">
<desc>Punctus Elevatus</desc>
<graphic url="punct-el-JR.png"><desc>Punctus Elevatus as rendered by the Junicode Regular Font</desc></graphic>
<graphic url="punct-el-JI.png"><desc>Punctus Elevatus as rendered by the Junicode Italic Font</desc></graphic>
<graphic url="punct-el-And.png"><desc>Punctus Elevatus as rendered by the Andron Web Scriptor Font</desc></graphic>
</char>

It seems silly to have to move this burden to processing and to substring-matching to then test everthing after the second - but before the .png to see which font it is, to create the equivalent of an @html:alt attribute. Since all html:img elements should have @alt attributes to comply with web accessibility guidelines, I think we need a way to store the text that would be used to make this @alt attribute at the site of the <graphic/> element. Other alternatives include a @desc attribute or similar but that is a step backwards into the icky free-text attribute days. Another possiblity would be to allow macro.xtext inside graphic and state that this was a description of the graphic (not a transcription).

-James

Discussion

  • Lou Burnard
    Lou Burnard
    2009-10-01

    I think permitting <figDesc> vel sim within <graphic> would lead to confusion as to where the description should go, and would prefer to keep <graphic> "pure". Maybe a better way of addressing your use-case would be to allow <figure> as a child of <char> rather than model.graphicLike

     
  • Lou Burnard
    Lou Burnard
    2009-10-01

    • milestone: --> 871214
     
  • James Cummings
    James Cummings
    2009-10-04

    For backwards compatibility I'd like to see graphic at least maintained there. But am happy with this suggestion generally. However, would also be happy with (graphic|figure) i.e. a choice between graphic or figure. though I suppose that unecessarily complicates the content model. (And then a use case would appear which wanted both graphic and figure inside char).

    Ok, I'd agree that retaining model.graphicLike but adding also figure here would be useful.

     
  • James Cummings
    James Cummings
    2009-10-04

    • assigned_to: nobody --> louburnard
     
  • Peter Boot
    Peter Boot
    2009-10-13

    We made figure global only recently. I'd say this means we should use it where its facilities (such as figDesc) are needed, and add it to char's content model.

     
  • Lou Burnard
    Lou Burnard
    2009-10-13

    agreed by council

     
  • Lou Burnard
    Lou Burnard
    2009-10-13

    • milestone: 871214 --> 871213
     
  • Lou Burnard
    Lou Burnard
    2009-10-17

    • status: open --> closed-fixed
     
  • Lou Burnard
    Lou Burnard
    2009-10-17

    <figure> contains model.graphicLike, so adding it as an alternative would lead to an ambigiuous content model.
    Replacing model.graphLike with figure has the advantage of adding some other possibilities we might want here; the disadvantage of breaking existing documents which contain <graphic>s . But repairing the break is pretty trivial, and there are likely to be very few people affected (other than James :-() so on balance I am going to go with Council's clear wish to make the proposed change.

     
  • James Cummings
    James Cummings
    2009-12-11

    Council solved my initial use-case for this, by allowing <figure> inside <char>. However, that was only one use-case. Another one is the use of <graphic/> elsewhere, for example inside <facsimile> where you want to provide different graphics and give descriptions of them.
    i.e.
    <surface>
    <graphic url="http://foo.com/abc1234.jpg"/>
    <graphic url="http://foo.com/abc1234a.jpg"/>
    </surface>

    The remote images are potentially on a server out of the user's control, and so they can't rename these 'hi-res.jpg' and 'low-res.jpg', <graphic/> is not a member of att.typed so you can't categorise them that way. Moreover you might want to provide a description of the graphic for use as html:@alt text. ...exactly the suggestion made in the original request. While the solution (figure in char) did solve my immediate problem, it doesn't solve the underlying one.

    So I've re-opened this ticket and set it back to amber.

    Potential solutions are:

    a) add graphic to att.typed, and allow an optional model.descLike content (exactly on the model of and basically same reasons as with <gap/>)
    b) allow figure inside facsimile/surface (which seems worse to me).

    -James

     
  • James Cummings
    James Cummings
    2009-12-11

    • milestone: 871213 --> AMBER
    • status: closed-fixed --> open-fixed
     
  • BODARD Gabriel
    BODARD Gabriel
    2009-12-11

    This is precisely my use-case at the moment: I am converting from EpiDoc P4 to P5, and the P4 texts had the epigraphic photographs tagged as figures within a div[@type=figure]; each photograph had a URL and a caption (figDesc).

    Since these photographs are (in one way or another) illustrations of the text, to which we might want to point from parts of the transcription, say, it seemed ideal to have these in <facsimile> rather than a typed div. But I don't see anywhere in facsimile that I can include a free-text description of the photograph. <surface> takes <desc>, so in theory I could have a surface for each image, containing both a graphic and a desc, but this smacks of abuse, since sometimes we have multiple photographs of the same face of the same piece of stone.

    Allowing <desc> on <graphic> would certainly solve this problem, and I can't think of any other way to do so at the moment, so I support James's suggestion (a).

     
  • Lou Burnard
    Lou Burnard
    2010-02-11

    Actually, you probably want model.glossLike as its content, so you can say how uncertain you are about thids graphic too ...

     
  • Yes, if we are having model.glossLike on space and such, can we have it on graphic as well?

     
  • Lou Burnard
    Lou Burnard
    2010-04-06

    • status: open-fixed --> closed-fixed
     
  • Lou Burnard
    Lou Burnard
    2010-04-06

    Implemented at rev 7384. Example in text needed .