Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#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

1 2 > >> (Page 1 of 2)
  • 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

     
1 2 > >> (Page 1 of 2)