[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 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC