Victor Mote wrote (August 8):
> Manuel Mall wrote:
>
> > Regarding the "bolder", "lighter" issue and the general
> font selection
> > I looked at the "pre-patch for FOrayFont adaptation to Fop"
> > (http://issues.apache.org/bugzilla/show_bug.cgi?id=35948) and
> > concluded that meddling with the font selection system will
> interfere
> > with the FOray font integration and that the FOray font system has
> > addressed most of the font selection issues any way (not sure about
> > the "bolder", "lighter" bits though).
> > I will therefore back-off from that line of work and wait for the
> > FOray font integration to complete, assuming that it is still going
> > ahead.
>
> Sorry to be so slow responding. I think Vincent is taking
> August off, but is still working on the font integration work.
>
> Manuel and I have had an off-line conversation about the
> bolder/lighter issue, and I think we will need to improve
> both the interface and the implementation to handle this and
> the similar issues for font-stretch. I'll work on that in the
> next week or two.
First, sorry to be so slow. I can finally get to all my tools again.
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!!??!!
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.
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.
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.
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.
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.
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.
> > BTW, while very briefly looking at parts of the FOray/aXSL font
> > selection code I noticed at least one instance where it relied on a
> > JDK
> > 1.4 API call. Not quite what we want for FOP I believe but
> I am sure
> > easy to fix for Victor.
>
> Yes, we should be able to get a 1.3 solution for this. BTW,
> FOray is theoretically dependent on 1.4. However, I don't
> know that there are any 1.4 dependencies in the font code.
I have removed the 1.3 dependency noted in aXSL. There may be others that
need to be addressed to retrofit for 1.3 use.
Victor Mote
