xslt.base.fo.graphics.xsl Maven / Gradle / Ivy
Hotspots on imageobjectco are not supported in XSL-FO
Warning: audio and video objects are ignored in XSL-FO output
Process an image
FIXME:
If only the content-area is specified, everything is fine. (If
you ask for a three inch image, that's what you'll get.)
If only the viewport-area is provided:
If scalefit=1, treat it as both the content-area and the
viewport-area. (If you ask for an image in a five inch area, we'll
make the image five inches to fill that area.)
If scalefit=0, ignore the viewport-area specification.
This is not quite the right semantic and has the additional
problem that it can result in anamorphic scaling, which scalefit
should never cause.
If both the content-area and the viewport-area is specified on a
graphic element, ignore the viewport-area. (If you ask for a three
inch image in a five inch area, we'll assume it's better to give you a
three inch image in an unspecified area than a five inch image in a
five inch area.
Relative units also cause problems. As a general rule, the
stylesheets are operating too early and too loosely coupled with the
rendering engine to know things like the current font size or the
actual dimensions of an image. Therefore:
We use a fixed size for pixels, $pixels.per.inch
We use a fixed size for "em"s, $points.per.em
Percentages are problematic. In the following discussion, we speak
of width and contentwidth, but the same issues apply to depth and
contentdepth
A width of 50% means "half of the available space for the
image." That's fine. But note that in HTML, this is a dynamic property
and the image size will vary if the browser window is resized.
A contentwidth of 50% means "half of the actual image width".
But the stylesheets have no way to assess the image's actual size.
Treating this as a width of 50% is one possibility, but it produces
behavior (dynamic scaling) that seems entirely out of character with
the meaning.
Instead, the stylesheets define a $nominal.image.width and
convert percentages to actual values based on that nominal size.
Scale can be problematic. Scale applies to the contentwidth, so
a scale of 50 when a contentwidth is not specified is analagous to a
width of 50%. (If a contentwidth is specified, the scaling factor can
be applied to that value and no problem exists.)
If scale is specified but contentwidth is not supplied, the
nominal.image.width is used to calculate a base size
for scaling.
As a consequence of these decisions, unless the aspect ratio of
your image happens to be exactly the same as (nominal width / nominal
height), specifying contentwidth="50%" and contentdepth="50%" is NOT
going to scale the way you expect (or really, the way it should).
Don't do that. In fact, a percentage value is not recommended
for content size at all. Use scale instead.
Finally, align and valign are troublesome. Horizontal alignment
is now supported by wrapping the image in a
<div align="{@align}"> (in
block contexts!). I can't think of anything (practical) to do about
vertical alignment.
Markup for the image.
0
0
0
1
1
0
1.0
1.0
auto
auto
auto
auto
auto
%
scale-to-fit
auto
auto
%
scale-to-fit
auto
before
center
after
auto