RE: Relative font weights and font selection

[Victor Mote]

Victor Mote wrote (on Monday):

> The following methods have now been added to org.axsl.font.Font:
> public byte nextBolderWeight() ;
> public byte nextLighterWeight() ;
> public Font nextBolderFont() ;
> public Font nextLighterFont() ;
> 
> public int unavailableChar(String string, int beginIndex) ;
> public int unavailableChar(char[] chars, int beginIndex) ;
> public int[] unavailableChars(String string, int beginIndex) ;
> public int[] unavailableChars(char[] chars, int beginIndex) ;
> 
> and a char has been added to the signature of the method 
> org.axsl.font.FontServer.selectFont.
> 
> Stub implementations have been created in FOray, but the 
> added functionality is, in general, not actually in place 
> yet. I'll get to that as I am able, but at least those 
> working with the interface can move forward when they are ready.

FOrayFont now has fully functional implementations of all of these methods,
and its font selection logic has been upgraded to use them. With the
*possible* exception of font-selection-strategy (I will start a separate
thread on this issue shortly), I think that FOray's font selection is now
fully conformant.

FOrayFOTree has also been upgraded to use the font-selection properly, and
to compute the relative font weights using the new aXSL font methods. If it
helps, Vincent and Manuel can use this as a template when implementing in
FOP. The only real trick in FOray was getting the first chunk of text that
should be considered. If that task is difficult in FOP, and you wish to
defer it, you can probably safely do so by sending the space character 0x20
to the FontServer.selectFontXSL method. Most, if not all, fonts will be able
to encode that character.

There are some user issues that result from the new conformity, WRT
simulating small-caps. The small-caps simulation logic that FOray inherited
from FOP had the following features:
1. Used a hard-coded 80% figure.
2. The decision to use small-caps at all, always simulated, was made
entirely outside of the font system.
3. Actual simulation of small-caps took place outside of the font system.

In order to build a conformant font selection, items 1 and 2 above have been
pulled into the font system. The aXSL font configuration DTD now includes
for the font-description element an attribute called "simulate-small-caps",
which takes a percentage. Existence of the simulate-small-caps attribute
also allows the font-description to be selected for either
font-variant="normal" or font-variant="small-caps" requests. User must now
provide a "simulate-small-caps" attribute for small-caps simulation to even
be considered in the font-selection process. The font-selection logic should
pick a true small-caps variant before picking one that merely simulates
small-caps. Also the following method has been added to the Font interface
to expose the new information provided in font configuration:
public int smallCapsSize(int fontSize);

This method returns the fontSize that should be used for intrinsically
lowercase characters. Remember that the font system doesn't know when
small-caps simulation is actually being used (item 3 above). It only knows
whether it can be used or not, and, if so, the scaling factor that should be
applied.

BTW, the DTD now also includes the following font-description attributes:
  simulate-oblique CDATA #IMPLIED
  simulate-backslant CDATA #IMPLIED
  simulate-ultra-condensed CDATA #IMPLIED
  simulate-extra-condensed CDATA #IMPLIED
  simulate-condensed CDATA #IMPLIED
  simulate-semi-condensed CDATA #IMPLIED
  simulate-semi-expanded CDATA #IMPLIED
  simulate-expanded CDATA #IMPLIED
  simulate-extra-expanded CDATA #IMPLIED
  simulate-ultra-expanded CDATA #IMPLIED

These are intended for aXSL implementation that wish to simulate font-style
and font-stretch values. I have documented these pretty heavily in the DTD
itself for those who want more detail.

Victor Mote

Re: Relative font weights and font selection

[Vincent Hennebert]

Victor Mote a écrit :

The following methods have now been added to org.axsl.font.Font:
public byte nextBolderWeight() ;
public byte nextLighterWeight() ;
public Font nextBolderFont() ;
public Font nextLighterFont() ;

public int unavailableChar(String string, int beginIndex) ;
public int unavailableChar(char[] chars, int beginIndex) ;
public int[] unavailableChars(String string, int beginIndex) ;
public int[] unavailableChars(char[] chars, int beginIndex) ;

and a char has been added to the signature of the method
org.axsl.font.FontServer.selectFont.

Stub implementations have been created in FOray, but the added functionality
is, in general, not actually in place yet. I'll get to that as I am able,
but at least those working with the interface can move forward when they are
ready.


That seems pretty well to me. As it also isn't urgent for me to implement this 
I'll wait before looking at it into more details.

But that should let doing the trick.

Thanks,
Vincent

RE: Relative font weights and font selection

[Victor Mote]

Victor Mote wrote (August 27, 2005):

> > > 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();

...

> > > 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.
> > 
> > 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.

The following methods have now been added to org.axsl.font.Font:
public byte nextBolderWeight() ;
public byte nextLighterWeight() ;
public Font nextBolderFont() ;
public Font nextLighterFont() ;

public int unavailableChar(String string, int beginIndex) ;
public int unavailableChar(char[] chars, int beginIndex) ;
public int[] unavailableChars(String string, int beginIndex) ;
public int[] unavailableChars(char[] chars, int beginIndex) ;

and a char has been added to the signature of the method
org.axsl.font.FontServer.selectFont.

Stub implementations have been created in FOray, but the added functionality
is, in general, not actually in place yet. I'll get to that as I am able,
but at least those working with the interface can move forward when they are
ready.

Victor Mote

Re: Relative font weights and font selection

[Vincent Hennebert]

Victor Mote a écrit :
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?


Yes, except the end: we agree that it would not be the purpose of the font 
config file to solve font-stretch. What I meant is that we could use a 
workaround by specifying different font families for expanded fonts; e.g. one 
family Times-Normal and one Times-Expanded, instead of one family Times with to 
font-stretch variants, Normal and Expanded. The user, instead of changing the 
font-stretch property, would change the font-family.




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.


I'll put the problems of font-stretchability and glyph substitution on my 
personal todo list. I may consider those problems later, when I'm (at last!) 
finished with the font integration work.


Vincent

RE: Relative font weights and font selection

[Victor Mote]

Manuel Mall wrote:

> I am with Vincent on this one. Here is the text for "wider" 
> from the spec ("smaller" is defined the same way): 
> The relative keyword "wider" sets the value to the next 
> expanded value above the inherited value (while not 
> increasing it above "ultra-expanded").
> 
> Note how it refers to setting the value of the property. No 
> reference to the font selection process.
> 
> Now contrast that to the definition of "bolder" in the spec: 
> Specifies the next weight that is assigned to a font that is 
> darker than the inherited one. If there is no such weight, it 
> simply results in the next darker numerical value (and the 
> font remains unchanged), unless the inherited value was 
> "900", in which case the resulting weight is also "900".
> 
> Here it talks about weights assigned to fonts, etc.. 
> 
> The two mechanisms sound quite different to me.

The good news here is that this is entirely a client (FOP) matter. If you
change your mind later, we can always add methods to the interface similar
to those used for font-weight.

> > 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?
> >
> I am not a committer but I do agree with your sentiments. 
> Probably the most important "side-effect" of the FOray font 
> integration with respect to the font selection process would 
> be support for font family lists in font specifications. This 
> is currently not supported and is in my opinion a compliance 
> "must" case before release (not for the 1.0 pre beta but after that).

I agree that this does not all need to be solved today. I just wanted to
generally acknowledge that the interface is not complete, that there are
issues still to be addressed. And a case could be made that font-family
lists are not properly supported unless the supported character set is
considered. I'll work on making and implementing the interface changes
discussed, and you guys can use them whenever you are ready.

Victor Mote

RE: Relative font weights and font selection

[Victor Mote]

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 
> art

Re: Relative font weights and font selection

[Manuel Mall]

On Fri, 26 Aug 2005 10:35 pm, 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.
>
I am with Vincent on this one. Here is the text for "wider" from the 
spec ("smaller" is defined the same way): 
The relative keyword "wider" sets the value to the next expanded value 
above the inherited value (while not increasing it above 
"ultra-expanded").

Note how it refers to setting the value of the property. No reference to 
the font selection process.

Now contrast that to the definition of "bolder" in the spec: 
Specifies the next weight that is assigned to a font that is darker than 
the inherited one. If there is no such weight, it simply results in the 
next darker numerical value (and the font remains unchanged), unless 
the inherited value was "900", in which case the resulting weight is 
also "900".

Here it talks about weights assigned to fonts, etc.. 

The two mechanisms sound quite different to me.

> > 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?
>
>

Re: Relative font weights and font selection

[Vincent Hennebert]

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

Re: Relative font weights and font selection

[Jeremias Maerki]

On 26.08.2005 15:00:46 Victor Mote wrote:
> Jeremias Maerki wrote:
> 
> > I believe that font-stretch has to included just like 
> > font-weight to select the actual font.
> 
> Sorry to be unclear. I understand that font-stretch must be included. The
> issue is whether the "wider" and "narrower" constraints can be processed in
> the FOTree by simply bumping the description up / down, or whether (as seems
> to be the case for font-weight) they must be resolved in the font system by
> looking at the actual fonts available. I originally read the spec to mean
> the latter, 

Me, too.

> but I think Manuel reads the spec as the former. I am not sure
> which is right. If the latter is correct, then we will need to do something
> similar to what I have described for font-weight to handle the font-stretch
> relative values.



Jeremias Maerki

RE: Relative font weights and font selection

[Victor Mote]

Jeremias Maerki wrote:

> I believe that font-stretch has to included just like 
> font-weight to select the actual font.

Sorry to be unclear. I understand that font-stretch must be included. The
issue is whether the "wider" and "narrower" constraints can be processed in
the FOTree by simply bumping the description up / down, or whether (as seems
to be the case for font-weight) they must be resolved in the font system by
looking at the actual fonts available. I originally read the spec to mean
the latter, but I think Manuel reads the spec as the former. I am not sure
which is right. If the latter is correct, then we will need to do something
similar to what I have described for font-weight to handle the font-stretch
relative values.

> > 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 think this is really up to the user agent to define the 
> exact strategy as long as the "visual order" is preserved.

OK. That is a third theory.

> > 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.
> 
> I got the impression that's what the spec tried to establish. Hmm.

I have never seen such a thing explicitly. I have been working under the
assumption that font A could be part of two font-families if a user wished
to do so. (I am not sure why a user would want to do so -- this was just
known to be possible with the data structured as it is).

Thanks for your comments.

Victor Mote

Re: Relative font weights and font selection

[Jeremias Maerki]

On 25.08.2005 18:10:51 Victor Mote wrote:
> 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.

I believe that font-stretch has to included just like font-weight to
select the actual font.

If you look at Adobe's Kepler collections below you have all the
font-weight variants for each of the three font-stretch variants (Std,
SemiCondensed and Extended). It's simply an additional dimension in the
matrix to choose a font. Not that font-stretch is used so often. That's
probably the reason why it was removed. CSS probably doesn't need this
level of detail for font selection, but XSL-FO might just be a little
closer to the market where people are very picky about what font they
use. Anyway, nobody uses 32 font variants in one document and a little
font mapping configuration would do away with the need for font-stretch.
So supporting font-stretch and font-size-adjust are low-priority
especially since they are both in the "Extended" conformance level.
http://store.adobe.com/type/browser/P/P_1432.html
http://store.adobe.com/type/browser/P/P_1435.html
http://store.adobe.com/type/browser/P/P_1437.html

> Interestingly, CSS 2.1 (the only version of CSS 2 still available at W3C)
> removes font-stretch entirely!!??!!

font-size-adjust was removed, too.

CSS versions at W3C:
http://www.w3.org/TR/REC-CSS1
http://www.w3.org/TR/REC-CSS2/
http://www.w3.org/TR/CSS21/

> 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 think this is really up to the user agent to define the exact strategy
as long as the "visual order" is preserved.

> 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.

I got the impression that's what the spec tried to establish. Hmm.

> 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.

I like that!

> Betw

RE: Relative font weights and font selection

[Victor Mote]

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

Re: Relative font weights and font selection

[Vincent Hennebert]

Victor Mote a écrit :

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.


I confirm. Still one week offline (I'm connected only tonight) and I get back on 
my work on font integration.




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.


There was a TODO in the code where "bolder" and "lighter" should be handled. 
I've left it as is for now as it is not very important yet. I had the feeling 
that the new font mechanism would ease things but as you say there seems to be 
some work to do. We will have to discuss about that one day...


Cheers,
Vincent

RE: Relative font weights and font selection

[Victor Mote]

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.

> 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.

Victor Mote

Re: Relative font weights and font selection

[Manuel Mall]

Jeremias,

fair enough. I have done the "larger", "smaller" bits as they are 
constrained to the fop property subsystem and will post a patch later. 
They were quite a handy starting point in trying to understand the fop 
property system.  

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.

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.

Now back to the WIKI to find something to do.

Manuel

On Mon, 8 Aug 2005 01:04 am, Jeremias Maerki wrote:
> Sounds like a few changes are necessary. Frankly, "larger",
> "smaller", "bolder" and "lighter" are really not that important right
> now. I can't remember anyone ever asking for them (although I could
> have simply not paid attention). Yes, I think this could interfere
> with the FOray font integration work but so could the creation of the
> XML Graphics Commons subproject when that code is moved. Though this
> IS useful, if I could place a wish I'd rather you find an area of
> more practical value (just a personal opinion!). A full
> implementation of the "font-family" attribute would certainly be more
> useful. But if you wish to work on that nobody's going to say no.
> There are so many other little things that need to be improved, too
> (see the task list in the Wiki).
>
> Another important area would be URI resolution and proper and
> consistent resolution of relative paths. I think that is something
> that bugs especially our users through Cocoon. There are a few
> (older) notes about that in the Wiki. In this context it might be
> worthwhile to have a closer look at Batik's ParsedURL which I'd wish
> to see in XML Graphics Commons and used in FOP if that makes sense.
> This area could be something very very useful for the project and its
> users and be isolated enough for you not to get lost in FOP's
> complexity. Still, it's not a minor bit to chew. Anyway, it's up to
> you.
>
> On 06.08.2005 17:44:02 Manuel Mall wrote:
> > I was looking at how to implement support for relative font weights
> > ("bolder" and "lighter"). The spec says that a relative font weight
> > refers to the next lighter or bolder font. This means we cannot
> > simply subtract/add 100 to the weight but we have to find the next
> > font relative to the current font which is actually lighter or
> > bolder. For example if the current font weight is 400 for most of
> > the default fonts the next bolder font weight is 700. This means
> > this feature actually interacts with or is part of the font
> > selection process.
> >
> > This raises the question if the font selection algorithm needs to
> > be adjusted for this should it be fixed up to support for example
> > list of font family names, font variant and font stretch or even
> > the font selection strategy property including context characters,
> > etc.. The last bit (selection strategy, context characters, glyph
> > availability) may be a bit much for me to attempt at the moment but
> > the other bits look doable.
> >
> > My question for the experienced developers and those fop-devs who
> > look at the overall project: Is this something useful and sensible
> > to attempt at this point in time, i.e. leading up to a 0.9 release?
> > Would this cut across or interfere with the attempt to integrate
> > FOray's font system into FOP?
> >
> > Manuel
>
> Jeremias Maerki

Re: Relative font weights and font selection

[Jeremias Maerki]

Sounds like a few changes are necessary. Frankly, "larger", "smaller",
"bolder" and "lighter" are really not that important right now. I can't
remember anyone ever asking for them (although I could have simply not paid
attention). Yes, I think this could interfere with the FOray font
integration work but so could the creation of the XML Graphics Commons
subproject when that code is moved. Though this IS useful, if I could
place a wish I'd rather you find an area of more practical value (just a
personal opinion!). A full implementation of the "font-family" attribute
would certainly be more useful. But if you wish to work on that nobody's
going to say no. There are so many other little things that need to be
improved, too (see the task list in the Wiki).

Another important area would be URI resolution and proper and consistent
resolution of relative paths. I think that is something that bugs
especially our users through Cocoon. There are a few (older) notes about
that in the Wiki. In this context it might be worthwhile to have a
closer look at Batik's ParsedURL which I'd wish to see in XML Graphics
Commons and used in FOP if that makes sense. This area could be
something very very useful for the project and its users and be isolated
enough for you not to get lost in FOP's complexity. Still, it's not a
minor bit to chew. Anyway, it's up to you.

On 06.08.2005 17:44:02 Manuel Mall wrote:
> I was looking at how to implement support for relative font weights 
> ("bolder" and "lighter"). The spec says that a relative font weight 
> refers to the next lighter or bolder font. This means we cannot simply 
> subtract/add 100 to the weight but we have to find the next font 
> relative to the current font which is actually lighter or bolder. For 
> example if the current font weight is 400 for most of the default fonts 
> the next bolder font weight is 700. This means this feature actually 
> interacts with or is part of the font selection process.
> 
> This raises the question if the font selection algorithm needs to be 
> adjusted for this should it be fixed up to support for example list of 
> font family names, font variant and font stretch or even the font 
> selection strategy property including context characters, etc.. The 
> last bit (selection strategy, context characters, glyph availability) 
> may be a bit much for me to attempt at the moment but the other bits 
> look doable.
> 
> My question for the experienced developers and those fop-devs who look 
> at the overall project: Is this something useful and sensible to 
> attempt at this point in time, i.e. leading up to a 0.9 release? Would 
> this cut across or interfere with the attempt to integrate FOray's font 
> system into FOP?
> 
> Manuel



Jeremias Maerki