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

["Gershon L Joseph" <gershon@tech-tav.com>]

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