Victor Mote a écrit :
I am ignoring font-stretch for now. I am unclear whether it works similarly
to font-weight, or whether it is totally resolvable in the FO Tree.
Interestingly, CSS 2.1 (the only version of CSS 2 still available at W3C)
removes font-stretch entirely!!??!!
As I understand the spec, this works differently from font-weight and can be
resolved in the FO Tree: just select the next expanded value for "wider" or next
condensed for "narrower". The font selection would be performed only after, when
it is time to decide e.g. which font the keyword "semi-expanded" matches.
That's true that it is an extra-feature that IMO can be simulated with a good
font configuration file.
For font-weight, there seems to be some ambiguity in the standard(s). There
are two possibilities, and neither CSS 2.1 nor XSL-FO seem to resolve the
matter:
1. Apply "bolder" and "lighter" to the inherited font to compute a weight
that is applied to the selected font.
2. Select the font, inheriting the weight from the inherited font, then
applying "bolder" and "lighter" to that weight.
I'd go with 1. Get the inherited font; find a darker one in the fonts database;
get its weight value. That's it.
In order to move forward, I suggest the addition of the following methods in
org.axsl.font.Font:
public byte nextBolderWeight();
public byte nextLighterWeight();
public org.axsl.font.Font nextBolderFont();
public org.axsl.font.Font nextLighterFont();
This will allow the client application (FOP) to use whichever algorithm it
thinks is appropriate. The bad news is that this ties each registered font
to exactly one font-family, something I was hoping to avoid.
That seems OK.
The only interest I see for a font to belong to several families is when there
is a specific family (Times, Helvetica) and a generic one (serif,
sans-serif...). In this case a generic family would be mapped to a specific one,
and I don't think your proposed methods prevents that. Otherwise I don't see
much interest to mix several families to build a complete set. The result would
be visually bad IMO.
I may have missed something: I haven't studied that point yet.
There is another area complexity in font selection that has not yet been
addressed, so I pose it here to Vincent and Manuel especially, and to any
others who wish to comment. The whole issue of whether the Font has a glyph
for the character(s) has not yet been addressed. The best idea I have for
this is as follows:
1. Add a char to the signature of org.axsl.font.FontServer.selectFont. This
char represents the first char of the text for which the font is being
selected. This allows the selection process to pass by a font-family if it
cannot paint the character.
So let's assume that I have a line of text to render. IIUC I would use it like
this:
* first call with the first char of the text to get the font that will be
generally used
* an additional call for each character for which there is no glyph in the
general font
Is that what you mean?
2. Add the following method to org.axsl.font.Font:
/**
* Examines each character in string to ensure that a glyph exists in
the font for that
* character. If a character has no glyph in the font, the character's
index in string
* is returned.
* @return The index in string of its first character for which no glyph
exists in this
* font. If all characters in the string have glyphs in this font, -1 is
returned.
*/
public int unavailableChar(String string);
Add also an overridden version of this method with char[] as the
parameter.
Why not directly return an array of all indexes where there is a missing glyph?
Or add a beginIndex parameter so that one doesn't have to artificially recreate
a String made of the initial String minus all characters up to the first missing
glyph?
Between these two, I think an application should be able to efficiently
subdivide a chunk of text based on the various fonts that may need to be
used to process it.
In the long-term the font-selection-strategy will have to be implemented. The
preceding stuff may need to be completed.
Comments on any of this are very welcome. I had hoped to defer some of these
font selection issues for a while yet, and you guys are frankly ahead of me
in needing to resolve them, so I will be glad to react to those who may have
thought it through more than I have.
I wish I could be more helpful, but I haven't considered all aspects of the
problem yet and I don't catch the whole point. I'd like to first finish the font
integration work.
IMHO this feature is for now not that important. What do other committers think?
Vincent
