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


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

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

Subject: Re: DOCBOOK: Re: A proposal to clarify the semantics of DocBookgraphics

On Wed, Feb 06, 2002 at 10:31:32AM -0500, Norman Walsh wrote:
> / Yann Dirson <ydirson@fr.alcove.com> was heard to say:
> | On Wed, Feb 06, 2002 at 08:59:41AM -0500, Norman Walsh wrote:
> |> I propose that we add four additional attributes to DocBook graphic
> |> elements: content-width, content-depth, align, and valign
> |
> | ImageData only ever occurs within a container (ie. MediaOject,
> | InlineMediaOject, MediaObjectCO).  When such a container is used to
> | specify alternative image formats, it is likely that the viewport will
> | be the same for all alternatives.  Then what about moving
> | viewport-size attributes to the container instead ?
> Well, one reason is that you might want to express the dimensions
> differently for different alternatives. (In inches, for example, for
> EPS figures and in pixels for PNGs).

Hm, right.  But then, you may even want to have PNGs for print (in
inches) and PNGs for HTML (in pixels) - which remind us we're dealing
with this at an inadequate level anyway :}

> |> width
> |> 	  Specifies the width of the area in which the image will be
> |> 	  displayed (the reproduction area or viewport width). If
> |> 	  unspecified, the default value is implementation defined.
> |
> | Maybe we should specify what units are available here.  People willing
> | to put papersize-dependant information here will want to use length
> | units, and the meaning of those is well understood.
> I suppose we could identify a set of unit names. But I don't think we
> should make it a closed set.

> | To address the "scale to max width" problem, we will need something
> | like percentage values, which should be explicitely defined, for
> | example like "percentage values are relative to the maximum width
> | available to the processor".  But then, it seems to me that the only
> | useful value would be 100% - other values would be more of a
> | stylesheet issue (eg. "full-width images get a 5% margin").
> I'm not sure what the scale to max width problem is, exactly. I think
> I'm inclined to leave the meaning of percentages in width and depth
> implementation dependent, mostly because I'm concerned about the
> semantics of "the maximum width available to the processor".
> | Maybe we just need a new value for scalefit ?  At the same time,
> | scalefit="1" could be replaced by something more adequate:
> |
> | 	scalefit	(none|dimensions|max)	none
> |
> | where "dimensions" would stand for "1" (which we could keep for some
> | time for compatibility).
> How is "max" different from "dimensions". Scalefit isn't anamorphic.

scalefit as you describe it (ie. current scalefit="1") scales to the
given width/height, for which semantics are only obvious when they are
lengths.  scalefit="max" would tell the processor to ignore the (IMHO
papersize-specific) width/height attributes, and have the processor
select the viewport itself (which would allow it to lay them out with
a consistent size wrt column width, consistent margins, etc, for all
papersizes - which scalefit=1 on absolute lengths cannot provide, and
for which scalefit=1 on % width/height seem to me somewhat inadequate,
as I described).

> |> content-width
> |>         Specifies the width of the actual image before scaling factors are
> |>         applied. If unspecified, the default value is the natural width of
> |>         the image. If the processor cannot determine the natural width of
> |>         the image, the results are implementation defined.
> |
> | I'm not sure what that means.  The "natural width" of the image refers
> | to a number of pixel for bitmaps, and in a (default) length for vector
> | drawings, right ?
> |
> | Is this just intended to hint the processor about dimensions it would
> | not be be able to determine ?
> |
> | What is supposed to happen when the processor knows about dimensions ?
> If I say content-width="3in", I want the image to be 3in across.

Hm.  I'm not sure I understand the wording "to be 3in across".  How
does it compare with width="3in" ?

> | As the "scale it" idea seems not to make sense here, I'd suppose it
> | could be used to cheat about real dimensions, ie. crop (or not) the
> | image to the given dimension if it is smaller than the determined one,
> | and add some filling around it if it is larger ?
> |
> | Maybe we should just state that if the given width does not match the
> | real image width, the results are implementation defined as well ?
> If the content-width (after scaling) exceeds the width, we do say the
> results are implementation defined. If the content-width (after
> scaling) is less than the width, the image is positioned within the
> width according to the value of the align attribute.

I was not talking about the respective values of "content-width" and
"width" attributes, but about those of the "content-width" attribute
and the real size of the image.  In other words, what is supposed to
happen if you lie to the processor when you specify "content-width".

> | Something that wasn't discussed, and is not addressed here, would be
> | the ability to crop within the viewport.  That would allow, for
> | example, when discussing a screenshot, to include isolated parts of a
> | single image file in various places in the document.
> |
> | Such a feature would require to explicit the "implementation defined"
> | behaviour you mention, maybe with a "crop" attribute, like:
> |
> | 	crop	(crop|nocrop) #IMPLIED
> |
> | with the implied behaviour being implementation defined.
> I'm a little concerned about this because some systems may not be able
> to crop (or not to crop).

Yes, but there are many systems, for example, that are not able to
display MediaObjectCO correctly.  Maybe that does not make much

Yann Dirson <Yann.Dirson@fr.alcove.com>                 http://www.alcove.com/
Free-Software Engineer				      Ingénieur Logiciel-Libre
Free-Software time manager    	       Responsable du temps Informatique-Libre
Debian GNU/Linux developper <dirson@debian.org>

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

Powered by eList eXpress LLC