From: Nikolai Grigoriev (grig@renderx.com)
Date: Sun Nov 17 2002 - 16:10:09 PST
Hi Eliot,
thank you for your message. As usual, it gives us a good stimulus
to revisit our understanding of certain parts in the spec.
> I'm working on defining the best way to create a "dropped capital"
> effect using side floats. The key is specifying negative top and bottom
> margins so that the floated area just fits the glyph, so you get this
> type of effect:
Hm. Negative margins may work, but are not very well defined.
I'd rather suggest acting upon font-size/line-height and
text-depth/text-altitude to achieve a match between
the line-area and the glyph's bounding box.
> While you can figure out the margin values by trial and error, I was
> hoping to define a principaled approach that would produce the correct
> result regardless of what the fonts were set to. Unfortunately, I can't
> seem to find one.
Let's analyze this in more detail. I am going to show the reasoning
that we at RenderX do about it.
In the float, there is a block; and inside the block, there's a line area.
It is composed as follows:
- there is a baseline;
- the content rectangle of the line-area raises by text-altitude above
the baseline, and sinks by text-depth below it;
- around the content-rectangle, there is white space from either side
(half-leading) - just enough to bring the whole height of the allocation
rectangle to line-height.
So, the total height of the line-area is defined by line-height (I omit
complications due to font strategies, bigger font incursions etc).
But the position of the baseline inside this rectangle depends on
the interplay of text-depth and text-altitude; and both are font-dependent.
We use font's bounding box to determine these parameters in XEP.
Note that there is no way in XSL-FO to determine actual height
of a glyph - glyph's own bounding box is never taken in consideration.
In early days of RenderX, we have had a line-stacking algorithm
that used actual glyph heights - but were told by the XSL WG
that this was not a correct behaviour, and had to revert to uniform
text-depth/text-altitude values for all glyphs in a given font.
> In addition, XEP and XSL Formatter produce different
> results for the same markup--obviously there is some difference in the
> interpretation of something or an implementation difference allowed by
> the spec, but I don't know enough about the fine points of font metrics
> to know what it might be. I reread the section on inline areas and glyph
> areas but it didn't really help.
A fair amount of variation is possible in the method to determine
text-depth/text-altitude. Instead of font's BBox, one can use
its default ascender/descender for these parameters; this will
position the baseline differently with respect to line area margins.
In fact, we are now pondering the possibility to switch XEP's
interpretation in this point, or at least to make it configurable -
thank you for input :-).
> The key difference I'm seeing is that XEP uses a different value for
> "middle" and "central" baselines, while XSL Formatter appears to
> conflate them,
The spec defines them as different [see 7.13. Area Alignment Properties].
However, different interpretations for default text-altitude/text-depth
will inevitably bring to differences in the interpretation of 'central': ours
is in the middle of the font's BBox, and therefore higher than Antenna's.
If they use ascender/descender for text-altitude/text-height, than you
may simply ignore the diference between 'central' and 'middle': e.g.
for Helvetica, it will amount to 0.006 em. I believe that both
implementations are within the limits of the spec - at least they
are consistent.
> My questions are these:
>
> 1. Which implementation is more correct or are both equally appropriate?
See above. I believe that you can hardly expect a common policy in this
field: various font formats may supply different data about font metrics.
> 2. Is there a constant or otherwise knowable formula for top and bottom
> margin values that will eliminate the correct amount of space before and
> after? I was expecting it to be an integer multiple or even percentage
> of the font size (e.g., either 1em or 0.2em or something like that). The
> values I arrived at by trial and error for XEP are -0.15em for top
> margin, -0.2em for bottom margin, but I have no idea why those
> particular values work.
There can be no such formula, because these parameters are font-dependent.
Different fonts have different proportions: they place the baseline differently
with respect to line area margins, and the ratio between observed glyph height
and font-size is also different across fonts. However, if you have a
metric for a font with a known CapHeight parameter (in 0.001em units),
the following gives you a block that has zero whitespace before and
after regular capitals:
<fo:block text-depth="0"
text-altitude="{$CapHeight div 1000}em"
line-height="{$CapHeight div 1000}em">ABCD</fo:block>
You can then add padding before and after this block; but at least you
know exactly how much space you add.
You can also go the other way: fix text-altitude and line-height
in the above fo:block to some value X, and set font-size
to X * 1000 / CapHeight. This guarantees that your dropcap
is actually X in height.
> 3. Is there a better or more predictable way to achieve the dropped cap
> effect?
It is always going to be font-specific. However, I believe that the above
approach is useful: once you find the CapHeight value for a font,
you can separate font-dependent part of formatting from the rest.
(If you don't have CapHeight, look for Ascender: in most Latin
fonts, they coincide).
Best regards,
Nikolai Grigoriev
RenderX
-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo@renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html
This archive was generated by hypermail 2.1.5 : Wed Dec 18 2002 - 08:41:28 PST