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


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: Monday, 2006 January 23 14:31
> 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
> 


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