[Bug awt/30106] JDK-1.0-style logical font names

[roman at kennke dot org]

------- Comment #4 from roman at kennke dot org  2006-12-14 08:47 -------
(In reply to comment #3)
> (In reply to comment #2)
> 
> > I disagree. TimesRoman etc are not logical font names, but 'physical' font
> > names. (Logical names are Serif, SansSerif, Monospaced, Dialog, and 
> > DialogInput
> > -- refer to the API docs for java.awt.Font for more details). 
> 
> Well, Sun has corrected their mistake by now. My point is that they _did_
> use "TimesRoman", "Helvetica", and "Courier" as the logical fonts names
> in JDK 1.0. Admittedly, there was little difference between logical and
> physical font names back then. Unfortunately, I have no copy of the 1.0.2
> API docs lying around anymore to prove that, but the test case shows that 
> the JDKs still acknowledge the old names.

Yeah but only because they bundle fonts with these physical names in their JRE.
So to follow this behaviour of recognizing (guaranteed) we would have to ship
fonts with these names too.

> So, the question is whether we want bug-compatibility with Sun in this
> case, or not. 

This is not a case of compatibility only. What if an application requests
TimesRoman in the expectation to get a TimesRoman (the real one) but gets an
arbitrary other font that we decide to map to?

> > these work with the JDK is not strict backwards-compatibility, but only 
> > caused
> > by Sun bundling these fonts with JREs. I don't think that we should map 
> > these
> > names internally, as it is not at all correct. If one requests TimesRoman, 
> > he
> > would expect the font 'TimesRoman' be loaded.
> 
> Excatly. An (outdated) application that requests "TimesRoman" or "Courier"
> expects to get those, but with current classpath its gets "Dialog" in both
> cases. 

It wouldn't get TimesRoman anyway. At the very best it could get a similar font
family of the same class. E.g. for courier, we could map to monospace etc, like
you proposed. That is still not Courier though.

> > I guess that this would even work with GNU Classpath if you happen to have 
> > the
> > Microsoft TTF fonts installed and registered with fontconfig. There are
> > packages for many distros that pull in these (non-free) fonts.
> 
> I don't see how this could happen. The logical font name is not recognized, 
> and Dialog is substituted, regardless of what fonts are installed. Am I 
> missing something?

Yeah. Fonts are (or at least should be - if not then this is clearly a bug)
looked up as physical font names first. If a TimesRoman font is installed it
should be loaded. Remember that there are real fonts with the names that you
mention above.

I got to make up my mind on this a little. Probably it won't hurt and we should
simply apply the patch that you proposed. But we got to make sure that when a
font with one of these names is installed, that this gets loaded, and not
something that we decide to map to.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30106