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

["Esrig, Bruce (Bruce)" <esrig@lucent.com>]

Hi Paul,

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?

Best wishes,

Bruce Esrig

========================

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.

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.

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.

The author's intent is best stated relative to the available area. The
author may specify that only a certain percentage of the available width is
to be used. 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.

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.)

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. (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.)

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.

=======

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

=======

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.

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

=======================

From Paul Grosso's recent message to the DITA TC mailing list:

As I said in
http://lists.oasis-open.org/archives/dita/200601/msg00031.html
I have retracted point 3 from the proposal.  It is not 
necessary for now and has potential for getting too complex.

In the interest of keeping our DITA 1.1 release minimal
(and timely), I do not recommend we try to tackle point 3 
in DITA 1.1.  We can leave point 3 for a future version.

...

===============

From the message referenced at that URL:

After more discussion with our customers, we have
decided that #3 is not a requirement that is needed
often enough to warrant going into DITA 1.1.  Given
that supporting this requirement would require much
more complexity than supporting requirements #1 and #2,
and given that I don't want to hold up DITA 1.1, I
am now suggesting we just implement parts #1 and #2
of my proposed solution below for 1.1.

paul

-----Original Message-----
From: Grosso, Paul [mailto:pgrosso@ptc.com]
Sent: Wednesday, January 25, 2006 10:27 AM
To: dita@lists.oasis-open.org
Subject: RE: [dita] Suggestion for graphic scaling improvements in DITA
1.1


Thanks for your support, Gershon.

As far as multiple settings for image size, when I
talked to our customers, they said they would rather
handle that need, when it arises, via profiling for
the various outputs.  

Given this workaround, and given the overall desire
not to make DITA 1.1 too complex, I think we might
want to defer your suggestion to a later release.

As an aside, I'd point out that Gershon's example
had a 40% scaling factor which is not included in
DITA's scale attribute's current enumerated list of
choices.  When I asked our customers if they could 
live with DITA's scale attribute's set of choices,
they said no way.  They often need to scale, say, 25% 
or 133% or whatever, which reinforces my suggestion
that we change the type of the scale attribute to NMTOKEN.

paul

> -----Original Message-----
> From: Gershon L Joseph [mailto:gershon@tech-tav.com] 
> Sent: Wednesday, 2006 January 25 5:09
> To: dita@lists.oasis-open.org
> Subject: RE: [dita] Suggestion for graphic scaling 
> improvements in DITA 1.1
> 
> I fully support Paul's suggestion, since our clients have 
> similar issues.
> 
> One additional issue I'd like to raise for discussion on the 
> list is whether
> we should support two settings for each image sizing 
> attribute. Many of our
> clients have expressed the need to specify *one* image size 
> for on-line
> (HTML) output and *another* image size for print/PDF output. 
> Since output
> generally falls into two categories -- online or print, we 
> probably don't
> need to make it infinitely scalable. However, some users may 
> also publish to
> hand-held devices that could arguably require a third image size...
> 
> The cleanest way to support setting graphic scaling for 
> multiple outputs is
> possibly to predefine the order in which the target media's 
> scaling appears,
> and allow for a character that represents no scaling for that 
> media. For
> example, <image scale="60 40" ...> would imply that 
> HTML-based output is
> scaled 60%, while for PDF output we'll scale the image to 40%. <image
> scale="* 40"> means we use a default scaling, (or no 
> scaling?) on the HTML
> output. The default value makes less sense on the scaling 
> attribute, since
> we could easily specify '100', but it does make sense when 
> setting specific
> width and height settings for the graphic. (In my case, one 
> client scales
> their graphic for print/PDF and has most of them full-size 
> for HTML output.
> So specifying * for width would apply no scaling to the width of the
> graphic.)
> 
> If the TC feels we should defer my suggestion to after DITA 
> 1.1, that's OK
> with me. I just wanted to get this point on the table for 
> discussion, and
> thought it could be done as part of Paul's suggestion.
> 
> Gershon
> 
> 
> -----Original Message-----
> From: Grosso, Paul [mailto:pgrosso@ptc.com] 
> Sent: Monday, January 23, 2006 10:31 PM
> To: dita@lists.oasis-open.org
> Subject: [dita] Suggestion for graphic scaling improvements 
> in DITA 1.1
> 
> I spoke to Don, and he suggested I send a specific suggestion 
> for a DITA 1.1
> work item to the list in the area of graphic scaling.
> 
> EXECUTIVE SUMMARY
> =================
> DITA's support for graphic sizing--which just allows a number 
> of pixels to
> be specified for the graphic image size via the image 
> element's height and
> width attributes--does not meet our customer requirements. 
> I suggest we make some upward compatible changes to address at least a
> subset of these requirements.
> 
> DETAILS
> =======
> 
> Current situation
> -----------------
> The DITA spec is vague on the topic of what are valid values 
> for the image
> element's height and width attributes and what are the 
> semantics of these
> values.
> 
> In checking both the toolkit and the collective IBM 
> knowledge, I understand
> that, for HTML generation, the image height and width values 
> are passed
> through as-is implying that DITA's image's height and width 
> attributes must
> be unitless integers giving the number of pixels to which to scale the
> graphic image (in each direction) in the browser displayed 
> results.  For IBM
> PDF processing, the pixel values are converted to points 
> (assuming 96 pixels
> per inch and 72 points per inch), and that value is used.
> 
> 
> Requirements for graphic scaling
> --------------------------------
> 
> 1. It should be possible for users to specify a percentage
>    value to which to scale the intrinsic size of the image.
> 
> 2. It should be possible for users to specify an absolute size
>    for the image height and/or width using a numeric value and
>    unit of measure.  Allowable units should include: pc (pica),
>    pt (point), px (pixels), in (inches), cm (centimeters), 
>    mm (millimeters), and em (ems) as allowed by CSS and XSL-FO.
> 
> 3. To aid in reuse and minimize hardwiring style to the source,
>    it may be a requirement to allow a user to request that an
>    image be scaled to some percentage of the "available space".
> 
> One specific proposal
> ---------------------
> 
> 1.  Add the "scale" attribute to the "image" element, and
>     change the declared type of the scale attribute to NMTOKEN.
>     Define the allowable value space of the scale attribute
>     to be any unsigned integer.  This would be an upward
>     compatible change.
> 
> 2.  No change needs to be made to the image element's height
>     and width DTD declarations, as NMTOKEN would allow all
>     values we wish to allow.  We would just augment the spec
>     to say that the value space of these attributes is a
>     length which is a real number with an optional unit
>     from the set of pc, pt, px, in, cm, mm, em.  An omitted
>     unit implies pixels so that existing documents will
>     continue to be treated the same way. 
> 
> 3.  This requirement could be met by allowing image element's
>     height and width attributes to take % values along with
>     some work to define what the "available space" is.  The
>     specific details of a suggested solution depend on the
>     exact user requirements which I'm still researching (and
>     would appreciate input from other users).
> 
> paul
> 
>