This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: 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
difference.
--
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>