This is the mail archive of the docbook@lists.oasis-open.org mailing list for the DocBook project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Image scaling (was Re: DocBook TC Meeting Minutes: 15 Jan2002)


On Wed, Jan 16, 2002 at 07:23:23AM -0500, Norman Walsh wrote:
> We have all the attributes we need, and we need all the attributes we
> have. (That some of this is presentational and not strictly semantic
> is something we have to live with, I think.)

I'm not really sure we need them, but this really needs more thought.
I can see the following use cases for imagedata:

- block or inline
- vector drawing or bitmap image
- fixed-layout (eg. printed) or media-independant (eg. HTML) output

My proposal was really oriented towards block display of vector
drawings for fixed-layout output, and I guess bitmap images for
media-independant output can just be passed through the toolchain
without changes (or does anyone needs scaling bitmaps here ?).  I'm
not familiar with uses of inline graphics (ie. what are they used for
by DocBook users), and the use of bitmap images for fixed-layout
output may not be easy to deal with in a generic way.


Here are a couple of remarks for the "block display of vector drawings
for fixed-layout output" use case:

> <imagedata fileref="image.eps" width="3in" depth="5in" scalefit="1"/>
> <imagedata fileref="image.eps" scale="120%">

Why do we want to scale a vector drawing, if not for optimal layout ?
This could be entirely left to the stylesheets (including margins,
etc.).


> <imagedata fileref="image.eps" width="3in" depth="5in"/>
> <imagedata fileref="image.eps" width="100%"/>

What we want here is the specification of a viewport on an image.

BTW, we currently have no means of specifying at the same time
that an image should be scale to fit some dimensions, and that they
should be rendered in a space of different size - which should be
useful I think (although not in the document itself).

This advocates for the viewport to be defined using other attributes.
And the "crop or overprint" probably should be specified by one of
those attributes - I can't think of a case where it wouldn't matter
that the image gets cropped or overprinted, my opinion is that is not
a stylesheet issue.

With additional viewport attributes, we could just use the same
semantics for the image size, with additionnal processing for the
viewport.



> <imagedata fileref="image.eps" width="100%" scalefit="1"/>
> 
> Renders an image scaled to a width (with properly scaled depth) of
> 100% of the available area. (What constitutes the available area
> depends on the context, of course. In print, it would usually be the
> column width.)

OK that's fine with me - except I feel that `width="100%"
scalefit="1"' should be the default for vector drawings.


Does this make sense to others than myself ?

-- 
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>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]