OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dita] Suggestion for graphic scaling improvements in DITA 1.1


In summary, I'd personally be happy to see some relative
sizing (aka scale-to-fit) in the fashion XSL-FO defines
and supports, but I still think this may strain the
tactics and goals of our minimalized 1.1 effort.

Comments embedded.

> -----Original Message-----
> From: Esrig, Bruce (Bruce) [mailto:esrig@lucent.com] 
> Sent: Wednesday, 2006 March 01 16:14
> To: Grosso, Paul
> Cc: dita@lists.oasis-open.org
> Subject: RE: [dita] Suggestion for graphic scaling 
> improvements in DITA 1.1
> 
> Enclosed is a framework of principles (below my signature) 
> that could help to correlate the various parameters that go 
> into the layout of graphics with the processes that are 
> primarily responsible for those parameters.
> 
> For DITA 1.1:
>  - Although you are not insisting on scale-width, if you'd 
> like to re-visit scale-width based on what follows, we might 
> be able to get enough agreement to introduce it.
>  - The interpretation that we use for the parameters that 
> specify intrinsic properties of graphics seems important. We 
> could either adopt the interpretation stated below 
> (supplement and/or override default information coming from 
> the graphic) or an alternative interpretation (more 
> output-oriented, stating the author's preferences). Which 
> interpretation do we mean the values to have?

We should probably ensure we match some existing interpretations
such as those in XSL-FO (and, in a much subsetted manner, in HTML).

> 
> ========================
> 
> A good choice in specifying the handling of graphics depends 
> on setting the context correctly.
> 
> What comes to the fore is the following paradox: how to offer 
> appropriate
> control to the author, the processing system, and the 
> presentation system.
> 
> Here is a candidate set of principles.
> 
> 1. The presentation system has final control over layout.

I'm not sure what this means when applied to a PDF viewer.
In what way does Acrobat, say, have control over the layout
of a graphic defined in the PDF file it is given as input?

> 
> 2. The processing system can define certain aspects of 
> layout, using what
> it knows about the output format, but making no assumptions about the
> presentation system.
> 
> 3. The author can define certain aspects of layout, using 
> what the author
> knows about the structure of the information, but making no 
> assumptions about output format or the presentation system.
> 
> 4. The graphic itself has intrinsic properties that influence 
> how it is laid out.

Usually, but not always.  My understanding is that not all 
graphic formats include intrinsic sizes.  But your point
remains valid.

> 
> Working backwards ...
> 
> 4. The graphic has one or more of the following intrinsic 
> specifications:
>  - a bitmap-like specification consisting of a height in 
> pixels, width in
> pixels, vertical resolution, and horizontal resolution
>  - a line-drawing-like specification consisting of a proportion
> height:width
>  - a suggested rendering size in physical units of height and width
> 
> 3. The author has an obligation to place the graphic within 
> the flow of the
> information. Anything the author says about the parameters 
> mentioned in 4
> is simply declarative, in order to compensate for some 
> inability of the
> systems to obtain that information from the graphic.

And which takes precedence if the author supplied information
differs from the intrinsic information?

> 
> The author's intent is best stated relative to the available area.

Sometimes, but not always.  Sometimes the author wants the graphic
at its intrinsic size or a given percentage of its intrinsic size
(magnification), and sometimes the author wants the graphic to have 
a given size (e.g., 4in width).  In fact, when I asked our authors 
and customers, they said most of the time they would be happy if they 
could specify a given size or a magnification of the intrinsic size.
That is the feedback I got that led me to retract my point 3.

So, in short, my feedback disagrees with your statement above.

> The author may specify that only a certain percentage of the 
> available width is to be used.

This is scale-to-fit.  This is what we're discussing as to 
whether we want to provide for this capability in DITA 1.1.

The tricky bit here is defining "available width" in all cases.

> For symmetry, the author may specify that only a certain
> percentage of the available height is to be used; however, 
> this capability
> will rarely be needed, since the production and presentation 
> systems will
> be forced to scale inappropriately tall graphics even without 
> an author's instruction.

No, I don't grant that "the production and presentation systems 
will be forced to scale".  If the author (via a stylesheet or
direct method) specifies the size of a graphic, that's the size
at which it gets composed and presented, and if that size would
run off the page or screen, that's what happens.  Only if the
user requests that the graphic be scaled to fit would the system 
scale it.  (Maybe that's what you meant, but it sounded to me
like you expected the system to avoid overflowing the available
area even when we weren't doing scale-to-fit.)

> 
> 2. The production system has an obligation to adapt the graphic to the
> output format. It would be the production system that places a minimum
> requirement on resolution. (If the author is offered a 
> minimum-resolution
> parameter, that is only to permit the author to override the 
> lower bound on
> resolution that the production system would otherwise use. The author
> cannot assume that a resolution directive will be obeyed by the
> presentation system.)

I'm not sure I understand the above.

> 
> Given the intrinsic specifications of the graphic and the 
> instructions of
> the author, the production system, using what it knows about 
> the output
> format, transforms the graphic if necessary so that when 
> presented it will
> fit within the available (height and) width.

Only if scale-to-fit has been specified.

> (If the author is offered
> graphic specification parameters for the purpose of exceeding 
> the bounds of
> what the production system would otherwise select, these should be
> carefully distinguished from the intrinsic parameters that 
> describe the
> graphic. For example, if the author wants the user to see a 
> 300-dpi graphic
> at 72 dpi even if that requires scrolling, that should be 
> done through a
> scale-to-graphic-spec parameter that is clearly distinguished from the
> scale-to-width and scale-to-height parameters discussed earlier.)

I'm not sure what the above means/implies.

> 
> 1. The presentation system should be free to render the 
> graphic as it sees
> fit. It will presumably receive a graphic, possibly after 
> transformation by
> the production system, and an output-specific directive on 
> how to present
> the graphic. It may rescale the graphic (for example, to fit within a
> containing region) if the graphic was not already rescaled by the
> production system. If zooming is supported, it may also 
> rescale the graphic as the user zooms.

I don't see how a PDF renderer can change the size of the
graphic without screwing up the layout of the already
paginated output.  Perhaps I'm misunderstanding you here.

> 
> =======
> 
> In the above discussion, the role of stylesheets was not 
> mentioned. These
> are additional sources of specifications in the authoring, 
> production, and presentation phases.

Agreed.

> 
> =======
> 
> In terms of this discussion, my proposal would be to include 
> in DITA 1.1 an
> author specification scale-width that is expected to be a 
> percentage of the
> available area. The parameter is interpreted relative to any 
> framing that may be provided by the context.

It can get quite complicated to define "available area" (aka
"any framing" or "viewport" or "reproduction area").  You mention 
table cells, which are complicated enough, but there are many other
interesting cases.  For example, how big is a graphic that is 100% 
of the available width when the <image> element is:

1.  between two words within a <p>
2.  between two <p> elements within an <li> element that
    is nested within another <li> element that is nested
    within another <li> element?

I'd be loath to define "available area" differently than does
XSL-FO, and if/when we tackle scale-to-fit, I'd like for us to
parallel the XSL-FO properties.  DocBook has done something similar:
http://docbook.org/tdg/en/html/imagedata.html

But I'm still unsure whether we should do this in 1.1.

paul

> 
> Systems might have to make refinements to the interpretation. 
> For example,
> inside a table cell, the interpretation might be that in 
> determining the
> width of the column containing the table cell, the graphic 
> should not force
> the table cell wider than the specified proportion of the 
> width available
> for the table (the table cell is transparent with regard to 
> the parameter,
> but contains the graphic). Controlling the width of the 
> graphic within the
> table cell regardless of the width of the table cell with 
> respect to the
> page as a whole is left unresolved.
> 
> If other parameters are added, declaring the properties of 
> the graphic,
> they would be considered declarative, overriding the true 
> properties of the
> graphic, and requesting conversion during production if needed. This
> maintains an output-independent perspective, in which final 
> responsibility
> for production and presentation still reside with those later 
> processes.
> 
> Best wishes,
> 
> Bruce Esrig
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]