Vincent Hennebert wrote: > 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.
Just to be clear, I understand your last sentence to be addressing a different topic than the first part of this statement. That is, font configuration won't be at all involved with the *resolution* of font-stretch in what you have proposed. However, it may be involved from the standpoint of implementing a resolved font-stretch value in that font-stretch could be simulated using PostScript or PDF text parameters. Did I understand this correctly? > > 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. I think you understand it perfectly. You are correct on all points: 1) putting a font in multiple font families is not very important, 2) we can still alias a font-family to another one. > > 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? I guess so. It doesn't sound elegant or efficient, but I haven't thought of a better algorithm. Presumably the common case is that the first font selected works for all of the text. > > 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? OK. Probably in a separate method called unavailableChars. > 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? Yes. That definitely needs to be there. > > 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. For all of this, probably the best approach is for someone to do exactly what you have done above: suggest changes to the interface that will provide the information needed. Victor Mote
