Victor Mote a =E9crit :
> Vincent Hennebert wrote:
>>>I think I need a new method in FontConsumer to break the tie:
>>> public boolean preferFreeStandingFont();
>>>True breaks the tie in favor of free-standing font, false=20
>>breaks it in=20
>>>favor of system-font.
>>With a default of true, yes. Why not, but I'm not sure I=20
>>really need such a
>>method: I think I could manage to make my FontConsumer return=20
>>the right values for=20
>>depending on the selected renderer. So I propose you to wait,=20
>>before adding this method, that it turns out to be really useful.
> I don't mind waiting. The original scenario that you stated was that bo=
> the "isUsing" methods were returning true. Since that is possible, I su=
> I need a way to break the tie.
mmm, that makes me think of a potential problem. I may indeed need a=20
preferFreeStandingFont() method. See below.
>>>OK. Therefore, the fundamental problem here is that we are=20
>>>reference two different fonts, using the same font-family=20
>>name in the=20
>>>input document. Here are the possible ways we can do this:
>>>1. Use two different configuration files. Advantages: 1)=20
>>>Disadvantages: 1) Requires a new FontServer instance to manage the=20
>>>2. Allow two different configurations within the same=20
>>>Advantages: 1) still pretty straightforward. Disadvantages:=20
>>1) Need a=20
>>>new element in the font-configuration to distinguish between the=20
>>>2) Need some way to communicate to FontServer which=20
>>configuration to use.
>>>3. Allow a font-family-alias to reference two different font-family=20
>>>elements, one to be used when a system-font is desired, the=20
>>>free-standing font is desired. Actually, this could be even more=20
>>>flexible, just requiring something like the following:
>>> <font-family-alias alias=3D"sans-serif" default=3D"Helvetica">
>>> <alias-configuration name=3D"free-standing" family=3D"Helvetica"=
>>> <alias-configuration name=3D"system" family=3D"Lucida Sans"/>
>>> <alias-configuration name=3D"something-else" family=3D"Some Othe=
>>>Advantages: 1) Still pretty straightforward; 2) Could=20
>>>used for other variations. Disadvantage: 1) Need some way,=20
>>>new FontConsumer method, to tell which=20
>>"alias-configuration" should be used.
>>>4. Allow the <font-description> element to point to more than one=20
>>><font> instance. This seems too ugly to consider.
>>>5. Allow the <font> element to represent more than one=20
>>actual font. As=20
>>>previously discussed, I think this is a bad idea. I think=20
>>we can allow=20
>>>the <font> element to represent both a system-font and a=20
>>>font, but they are really different manifestations of the same font.
>>>I may have missed some possibilities. Can you see any others?
>>>Of the choices listed above, I think I like #3 the best. Do=20
>>>it meets your requirements?
>>I also prefer #3. Such aliases should IMO only be allowed for=20
>>the generic family names (serif, sans-serif, monospace),=20
>>because of the issue of getting the right real font for the=20
>>right renderer. I think that for other aliases, like "any",=20
>>the different flavours of "Times Roman", etc., the current=20
>>situation should be enough. But see my further comments below.
>>>>I'm getting the feeling that free-standing fonts and system fonts=20
>>>>should perhaps be clearly separated in the font-config file. This=20
>>>>would result in something like this:
>>>Yes, I am thinking about similar ideas also. There used to be a=20
>>>separate element for system-font. The problem is that
>>is that? ;-)
> Oops. I was starting to say ... The problem is that ... now we have the=
> capability of having a font that (although just one font) can manifest
> itself as either a SystemFont or a FreeStandingFont. So breaking the on=
> element into two brings some more confusion.
Ok, I agree.
>>>This almost convinces me that the FreeStandingFont=20
>>interface needs to=20
>>>come back along with a new SystemFont interface.
>>No, definitely not. The user will never know when he has to=20
>>use FreeStandingFont or SystemFont. Apart from the fact that=20
>>the Font interface got a bit cluttered up, I really was=20
>>relieved to see FreeStandingFont disappearing.
> OK. The problem here is that, for fonts that can manifest themselves as=
> a SystemFont and a FreeStandingFont, you view them as FreeStandingFonts=
> can return a java.awt.Font. I view them as SystemFonts that can return
> values for the embedding methods. The only reason I can think of to use=
> a font instead of just using it as a regular FreeStandingFont is becaus=
> want to use the java.awt.Font metrics system. IOW, if the user wants to=
> the FreeStandingFont manifestation for layout, since the FreeStandingFo=
> manifestation is the only one useful for embedding, they would just cre=
> normal FreeStandingFont and not add the attributes that would turn it i=
> SystemFont instead.
> After writing the above, I think I know the solution. In the case where=
> font can manifest itself as either a SystemFont or a FreeStandingFont, =
> system should return the SystemFont, and use the related FreeStandingFo=
> a totally hidden manner, to provide return values for the embedding met=
> You will then be able to get the java.awt.Font directly.
> I think that will work.
OK, it looks good. To summarize, we have 3 kinds of fonts:
1. free-standing fonts that can't be derived into an AWT font;
2. free-standing fonts for which an AWT font can be made available; this =
broken into 2 sub-categories:
2.1. font elements for which a system-name is specified (like for the=
2.2. font elements for which there's no system-name but that provide =
informations to let an AWT font be created (access to e.g. the ttf file)
3. system-only fonts: just a system-name attribute, no metrics-file, no f=
Now here's my problem: for PDF output, I want 1. and 2. For AWT rendering=
2. and 3. If fonts from 2. are represented as system fonts I can't set up=
FontConsumer to return false for isUsingSystemFonts(). But thus I may als=
pure system fonts.
What you propose can work, but to solve the problem a preferFreeStandingF=
may indeed be needed.
Update: writing the above has made me think of the following:
From a user POV I think it's better to give the priority to FreeStanding=
I'm a new user. I've just completed the default font-config file to add t=
high-quality fonts that I've purchased on my favourite foundry's site.
Now for the PDF rendering I configure the FontConsumer like that:=20
isUsingFreeStandingFonts returns true, isUsingSystemFonts returns false (=
care about the AWT fonts!!).
For the AWT rendering I do the following: isUsingSystemFonts returns true=
course, but isUsingFreeStandingFonts also returns true, in case my new fo=
be converted into AWT fonts.
From a user POV the above seems natural, because if he has given font-me=
and font-file informations in the config file he will consider the font t=
o be a=20
free-standing one. And he just won't understand why he can't get his new =
for the PDF rendering...
Do you follow me? That's the reason why I think it's better that a free-s=
font always returns an AWT font, with possibly a warning when falling bac=
the default. It will be IMO more user-friendly.
>>>Then each could have a method
>>>that gets their spouse. So, for example, FreeStandingFont=20
>>>the following method:
>>> public SystemFont getSystemFont();
>>>Then the getAWTFont method moves to the SystemFont=20
>>interface, where it=20
>>>should never return null. However, the getSystemFont() method above=20
>>>could return null if there is no spouse.
>>I would prefer to see getAWTFont return something for=20
>>free-standing fonts that can be registered with Java (which=20
>>will eventually be possible when this functionality is=20
>>supported), and null or a default AWT font with a warning for=20
> See above where I kind of turn this upside-down. The returned font will=
> instead be a SystemFont with usable embedding methods. The client
> application will still think it is dealing with one Font instance (alth=
> there are really two). This will allow the font that the user is using =
> retain its correct character as a SystemFont.
>>... what I propose is to freeze the API for now. When I'm=20
>>done with my adaptation work I'll probably have a better=20
>>overview of the whole thing, and find solutions that will=20
>>cleanly solve this problem and others that might have arisen=20
> OK. That just leaves me with the one change to do now, the one discusse=
> immediately above.
> However, I am going to take the liberty of completing the other one
> discussed earlier in this message: allowing a font family alias to alia=
> more than one font-family, depending on some new method in FontConsumer=
> below where I think that will be needed.
>>Currently I can get both PDF and AWT renderers working.=20
>>Thanks to the new
>>getSystemFontList() method I have been able to find the right=20
>>names of my registered fonts. Below I give 2 different=20
>>mappings of base12 fonts to system
>>fonts: one for Linux users, who almost all will have the=20
>>Nimbus clones installed on their systems (you can see that=20
>>the names couldn't be inferred); and one for Windoze users=20
>>who all have the default Times New Roman/Arial/Courier New fonts.=20
>>I don't know which is the situation for Mac Os. I'll ask a friend.
> Ah, but if we allow the alias to point to more than one family, why not=
> the Java logical names now instead of the actual font names? They just =
> to be set up in a different font-family from the free-standing variants=
Why not, but this would complicate the config file a bit further... The=20
advantage of the approach above is that the rendering will be the same fo=
PDF and AWT. As the Java logical names are mapped to the Lucida family th=
won't be the case if we use them. I think this is quite important because=
the AWT renderer as a convenient previewer that can quickly reload a docu=
That said, if the user wants such a situation he can easily change the co=
file to map the generic names to Times/Helvetica/Courier. It's also a bit=
logical to map the FO serif family to the AWT Serif font.
So, well, I don't really mind your change.
>>With these mappings it will be possible to have the generic=20
>>families working for both PS/PDF and AWT renderers. As the=20
>>actually used fonts will be compatible this might even help=20
>>to have the same rendering in PDF and AWT. After all the=20
>>situation isn't that bad.
>>I also think it's no use to add attributes to font elements=20
>>to make system font selection easier (the system-font-family,=20
>>system-font-weight, system-font-style mentioned in a previous=20
>>post). It's now easy enough with getSystemFontList() to find=20
> OK. Good. We can always add it later if we think we need to.
>>Attached is a very small utility that displays all the fonts=20
>>registered within a Java system. Who knows, some new users=20
>>writing their font-config files might find it useful.
> That is good. Maybe we should put that into aXSL?
Yes, why not.
> Also, you might look at
> the FOraySystemFont method that does this as it tests whether the user =
> a graphical environment (avoids stack trace on non-graphic Linux boxes,=
Good, thanks. I've changed my class in accordance, attached is the new ve=
>>I think we'd better leave the font configuration as is for=20
>>now and concentrate on adding new features like sub/super=20
>>script and font baseline informations as mentioned on=20
>>axsl-user. Or subset embedding, opentype support, glyph=20
> ... and the one I desperately need is glyph positioning, although it lo=
> like the new Acrobat may handle this for me.
> Let me know when you are ready to work on the baseline and sub/super sc=
> stuff. I haven't had a chance to work on it yet.
I'll quickly try to resurrect the PDF renderer, and have a look at the PS=
renderer. Then I think I'll start looking at those problems.