Re: Physical and logical fonts
failure_to@yahoo.co.uk wrote:
a)
So in essence, at the highest level ( I2"m talking about fonts in
general, not just in Java ) all fonts fall into one of five
categories( based on their visual appearance )?
And for that reason Java also has five logical categories and not six
or four?
Have you read the introductory blurb on
<http://java.sun.com/javase/6/docs/api/java/awt/Font.html>?
Java does not map all physical fonts to a logical font, so it doesn't
classify them. The logical fonts are, to use the JDK definition, "the
five font families defined by the Java platform which must be supported
by any Java runtime environment..."
b)
Say Java maps two physical fonts onto one logical font. Now even
though at the highest level visual appearances of these two fonts may
be similar, at the closer inspection the visual styles of these two
fonts may still be very different.
Thus won2"t the text displayed using this logical font be kinda odd
looking, since it will mix characters from two ( potentially )very
different visual styles?
The purpose of mapping multiple fonts to one logical font is to try to
get as much of the Unicode range covered as possible. It is possible to
mix and match crazily, but most fonts tend to cover specific ranges of
Unicode. The font I am currently using, for example, will cover all of
the printable characters below \u0100, as well as other various
punctuation characters, but not Hebrew, Arabic, or Japanese (among many
others). Japanese text from the beginning looks very different from
Latin text, so the mismatch from some of the visual appearances is not
as important.
2)
Java maps several physical fonts to one logical font and by doing that
enables visual representation of many characters. So why can2"t this
also be done when using AWT?
From the Java Internationalization FAQ (directed from the Font Java
docs page):
Why can I see some characters in Swing components, but not in peered AWT
components?
Swing user interface components use a different mechanism to render text
from peered AWT components. The Swing components use the
Graphics.drawString method, typically specifying a logical font name.
The logical font name is then mapped to a set of physical fonts to cover
a large range of characters. Peered AWT components on the other hand are
implemented using host operating system components. These host operating
system components often do not support Unicode, so the text gets
converted to some other character encoding, depending on the host
operating system and locale. These encodings often cover a smaller range
of characters than the physical fonts used to implement logical font
names. For example, on a Japanese Windows 98 system, many European
accented characters are mapped to the Arial font for Swing components,
but get lost when converting the text to the Shift_JIS encoding for
peered AWT components.
In short, it's not Java's fault, it's the OS.
4)
Say Java maps two physical fonts A and B to a single logical font. And
let us further assume that while A and B for the most part represent
different characters, they do however both represent same character U.
Now how does Java decide which glyph ( either from A or from B ) to
use to visually represent character U?
I believe it would pick the first one it finds. If A occurs before B in
the search path, it uses A's version.
5)
4) Can particular font support several encoding sets?
You mean UTF-8, ISO-8859-1 and so on? Java supports many such
character encodings / character sets.
It is not necessary for a font to explicitly support, say UTF-8.
When you write text to a UTF-8 text file, fonts are not
involved.
But fonts are involved when you want that UTF-8 file to be displayed?!
The application and the OS's font utilities are involved in doing the
mapping from the character set to the font's internal character and
glyph lookup. I can only speculate here, but I presume that the entire
conversion takes place before the font is actually looked up to display
the glyph(s).
If you have a wordprocessor that writes files containg text with
font data then the font info is in a separate part of the file
from the text, regardless of what encoding is used for the text.
Then how does wordprocessor know which glyph from particular font to
map to which character?
The word processor doesn't know, the font knows. The format specifies a
conversion from character(s) to glyph(s), as it is an M->N mapping.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth