[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Potential Missing Feature for Inline SVG: Display Width and Height
Actually, I agree with suggestion number 1 since other use cases are
possible for specializing foreign as a container for inlined
vocabularies that need to behave like images when rendered. This
element is our closest match to the behaviors you could get in SGML
with data notations, where you could pass in this kind of
contextually-needful info for use by the processor that would
actually embed the data object into the result view. It's just that
DITA does not have a nice general way to add any old property, as
Eliot noted. I lean towards making the solution easy for authors.
This element interfaces the other vocabularies into the DITA
rendering context, so it is most like <image> in that regard.
But since we can't use <image> as the specialization base for
SVG, Eliot's #1 solution is the nearest surrogate. I have often struggled with the pure objective of total separation of presentational data from XML. If DITA were a pure abstraction of a data model, that would be key goal indeed. But DITA is more like HTML in that it is primarily a means for representing content for publication, and in both languages, there is no graceful way to associate instance-specific display properties (unlike outputclass which applies to every use of an element) without making those properties part of the element instance itself. It is a matter of both ease of management and the reality that we are not really specializing pure abstractions--we are mapping abstract forms to DITA, which always adds its own baggage to any purely abstract or semantic model. Hence the reason why we see display-atts in other elements. As this applies to Eliot's suggestion, I would just add display-atts into foreign so that it can be more "in family" with those elements (meaning processors can use common code for all cases). -- Don On 5/17/2015 9:13 AM, Eliot Kimber
wrote:
...In implementing output processing for inline/referenced SVG for DITA 1.3 I've discovered that there's a small missing feature, namely the ability to specify an explicit width and/or height for the SVG. I think this means that we need to define a way for DITA document authors to specify explicit width and height for inline SVG graphics. I see these possible solutions: 1. Add @width and @height to <foreign>. This is an architectural change but would be easy to implement and is backward compatible. It would be useful for any use of foreign to contain data for which a width or height is meaningful. 2. Define specializations of <data> for use within <svg-container> (or within <foreign> generally) that specify width and height, e.g.: <svg-container> <display-width value="2in"/> <display-height value="2in"/> <svg:svg>...</svg:svg> </svg-container> This requires no architectural change but is slightly less convenient to author. 3. Do nothing and let the community define a convention that would be very much like option (2) or possibly some use of processing instructions but would not be part of the standard. I think I prefer option (1): It's simple and obvious and doesn't break anything. It makes <foreign> used for graphical data more parallel with <image> and doesn't risk tagname conflicts with existing custom domains. It would not require new element reference entries. --
Don R. Day
Founding Chair, OASIS DITA Technical Committee LinkedIn: donrday Twitter: @donrday About.me: Don R. Day Skype: don.r.day
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?" --T.S. Eliot
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]