Physical and logical fonts

F

failure_to

hello

I'm learning a bit about fonts and while the following link did help
to some extent,

http://mindprod.com/jgloss/font.html

there are still questions bugging me about the subject!

Again, I apologize for so many questions, but I think other thread
makers would not appreciate it much if threads on first page were all
made by little me ( I realize all bunch of questions in one thread may
turn off potential helpers and thus may not give long and thorough
explanations on all individual questions asked )



1) Since there are five logical fonts in java, then that would suggest
that not all physical fonts can be mapped to single logical font. So
what property makes physical fonts fall into one of five categories,
thus why not have just one logical category which could map to all
physical fonts?



2) I know java has build in physical fonts, but can logical fonts
themselves represent characters visually, or must they always be
mapped to physical fonts? Why?



3) I've read that logical fonts represent more characters than most
physical fonts do. Huh?! If logical fonts themselves can represent
characters, then why the need for mapping to physical fonts?




4) Can particular font support several encoding sets?



5) If answer is yes to the above question, then how do fonts relate to
character sets? For example:

Say we have a font that is able to display all ascii characters.
We also have two different 7 bit encodings EN_1 and EN_2. Both are
able to display all ascii characters. But they have different code
points for individual characters ( for example in EN_1 code point for
character A may be 65, while in EN_2 codepoint for A may be 100 ).

Is always creator ( programmer not god ) of this font the one which
enables support for both EN_1 and EN_2 encodings, or can this also be
done manually ( by manually I mean by local users who'd somehow map
individual glyph to particular codepoint )

thank you
 
R

RedGrittyBrick

1) Since there are five logical fonts in java, then that would suggest
that not all physical fonts can be mapped to single logical font.

It doesn't suggest any such thing to me[1].

On any given system, at any given moment in time, the JRE might map each
logical font name to exactly one physical font name.

In principle any of the five logical fontnames could be mapped to any
physical font present, and vice versa.

As you say, Java typically maps one logical font name to several
physical fonts in order to provide access to a wide range of glyphs.

There is presumably a limit to the number of physical fonts that can be
mapped to a single logical font. Also, on any typical system, adding
more fonts doesn't always extend the set of Unicode characters for which
glyphs are then available.

So
what property makes physical fonts fall into one of five categories,

None. There's a file that defines the mapping. Whilst it would be
foolish to map a proportional font to a monospaced font-name I don't
think there's much else to restrict you.

thus why not have just one logical category which could map to all
physical fonts?

Firstly because most GUI apps need more than font. Five visually
distinct fonts is a reasonable number to have available for most GUI apps.

Secondly because there is no point. The reason for mapping multiple
fonts to one logical name is simply to increase the number of characters
for which a glyph is available [2]. Since most fonts on your PC define
glyphs for exactly the same set of characters, adding another such font
to the mapping does not make any new glyphs available. See [2]

2) I know java has build in physical fonts,

The JRE is shipped with some TTF font files. That doesn't mean that any
physical fonts are built in to the JVM itself.

Java != JRE != JVM

but can logical fonts
themselves represent characters visually,
No.

or must they always be
mapped to physical fonts?
Yes


Why?

Because AFAIK [1] logical fonts consist of nothing more than a name and
a few characteristics. They contain no glyph data such as bitmaps or
scalable outlines etc.

3) I've read that logical fonts represent more characters than most
physical fonts do.

I think you've misread something. Where did you read that?


I expect Java is quite happy to attempt to display any Unicode value
using any logical font. The operating system will probably display most
of them as little boxes because no single physical font contains the
entire Unicode character set.

If logical fonts themselves can represent
characters,
then why the need for mapping to physical fonts?

See above Logical fonts don't contain any information about the visual
appearance of individual glyphs.

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. Ditto for
ISO-8859-1 or any other such encoding.

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.

5) If answer is yes to the above question, then how do fonts relate to
character sets? For example:

I recommend you read Wikipedia, it has some good articles on this subject.
Say we have a font that is able to display all ascii characters.
We also have two different 7 bit encodings EN_1 and EN_2. Both are
able to display all ascii characters. But they have different code
points for individual characters ( for example in EN_1 code point for
character A may be 65, while in EN_2 codepoint for A may be 100 ).

Is always creator ( programmer not god ) of this font the one which
enables support for both EN_1 and EN_2 encodings, or can this also be
done manually ( by manually I mean by local users who'd somehow map
individual glyph to particular codepoint )

You seem to be arbitrarily mixing up several concepts:

- character set
- encoding
- fontnames
- font files

In some circumstances you can indeed remap the association of particular
glyphs in a font to particular codepoints. For example this is often
done when printing using postscript type-1 fonts. It is called changing
the encoding vector. I'm not sure this is something a Java programmer
need be concerned with.


[1] Caveat emptor. I am not a Java font expert.
[2] http://java.sun.com/j2se/1.4.2/docs/guide/intl/font.html#lucida
 
L

Lew

Again, I apologize for so many questions, but I think other thread
makers would not appreciate it much if threads on first page were all

First page of what?

If you're referring to the display from a particular newsreader, be aware that
people use quite a variety of products to access Usenet. Heree, for example,
the newsreader is not page oriented.
 
L

Lew

RedGrittyBrick said:
Whilst it would be
foolish to map a proportional font to a monospaced font-name I don't
think there's much else to restrict you.

If the foolishness of an action restricted human behavior, there'd be a lot
less of it.
 
L

Lew

Firstly because most GUI apps need more than [one] font. Five visually
distinct fonts is a reasonable number to have available for most GUI apps.

Any more runs you into ransom-note typography, a common but egregious layout
mistake.

One guide I read years ago, and I believe Microsoft has some online material
to support this, suggested that one select one each of three types of font
family: a proportional serif font, a proportional sans serif font, and a
monospace font. Use the serif one for explanatory text, the sans serif one
for headlines and subject headings, prompts and the like, and the monospaced
one for special purposes. Rarely if ever should one put a fourth font family
into the mix. Size and stroke (normal vs. oblique) one may vary sparingly at
need.

Microsoft specifically recommends the Windows fonts Georgia (proportional
serif), Verdana (proportional sans serif) and Courier New (monospaced) for web
pages. Most places I've worked use Times New Roman (in a larger point size
than you'd use for Georgia), Arial and Courier or Courier New, respectively.

I personally am fond of the "Book(man)" and "Bitstream" category of fonts.
They have near equivalents in both the Linux and Windows worlds, too.
 
R

Roedy Green

1) Since there are five logical fonts in java, then that would suggest
that not all physical fonts can be mapped to single logical font. So
what property makes physical fonts fall into one of five categories,
thus why not have just one logical category which could map to all
physical fonts?

Even though your computer may have hundreds of fonts installed, with
AWT, you can only get at five of them, five chosen by Sun (unless you
use drawString). Sun chooses the physical fonts from ones it bundles
and ones known to be installed with the OS, and then maps the five
logical fonts onto the five chosen physical ones.

I am updating the entry at http://mindprod.com/jgloss/font.html to
clarify.
 
R

Roedy Green

2) I know java has build in physical fonts, but can logical fonts
themselves represent characters visually, or must they always be
mapped to physical fonts? Why?

If there were no logical fonts it would be impossible to write a
program guaranteed to run everywhere since they are no physical fonts
guaranteed to be installed everywhere. By mapping logical fonts to
physical fonts, monospaced for example can be mapped onto the most
popular monospaced font on a given platform, without Sun having to
licence and provide the physical font for every conceivable platform.
 
R

Roedy Green

3) I've read that logical fonts represent more characters than most
physical fonts do. Huh?! If logical fonts themselves can represent
characters, then why the need for mapping to physical fonts?

Which fonts get mapped is a property of the physical font. Sun chose
physical fonts with support for a wide selection of Unicode characters
to represent its logical fonts.
 
R

Roedy Green

Say we have a font that is able to display all ascii characters.
We also have two different 7 bit encodings EN_1 and EN_2. Both are
able to display all ascii characters. But they have different code
points for individual characters ( for example in EN_1 code point for
character A may be 65, while in EN_2 codepoint for A may be 100 ).

Java just uses the Unicode encoding and ignores the rest. Read up on
the OpenType format to understand how you can have multiple encodings.

see http://mindprod.com/jgloss/opentype.html
 
R

RedGrittyBrick

RedGrittyBrick said:
I think you've misread something. Where did you read that?

I think I see what's confusing you. The logical font name intrinsically
"represents" no characters. It is only the mapping of physical fonts to
the logical font name that supplies the visual representations of
characters (i.e. glyphs).


Lets pretend I am a typographer, I create four monospaced truetype fonts
as follows:

1. RGB-LETR.TTF containing glyphs for characters ABCDEF...XYZ
2. RGB-NUMR.TTF containing glyphs for characters 0123456789
3. RGB-PUNC.TTF containing glyphs for characters ,.:;'`"~
4. RGB-BRKT.TTF containing glyphs for characters ()[]{}<>

Now I install those fonts and edit font.properties to associate these
four physical fonts with the Java logical font "monospace".

None of my physical fonts has glyphs for more than 26 characters.
But logical font "monospace" now has glyphs for 52 characters!


Instead of A-Z, 0-9 - imagine different (or overlapping) subsets of the
Unicode set. One fonts might have the math symbols, another the arabic
glyphs, and so on.
 
L

Lew

RedGrittyBrick said:
I think I see what's confusing you. The logical font name intrinsically
"represents" no characters. It is only the mapping of physical fonts to
the logical font name that supplies the visual representations of
characters (i.e. glyphs).


Lets pretend I am a typographer, I create four monospaced truetype fonts
as follows:

1. RGB-LETR.TTF containing glyphs for characters ABCDEF...XYZ
2. RGB-NUMR.TTF containing glyphs for characters 0123456789
3. RGB-PUNC.TTF containing glyphs for characters ,.:;'`"~
4. RGB-BRKT.TTF containing glyphs for characters ()[]{}<>

Now I install those fonts and edit font.properties to associate these
four physical fonts with the Java logical font "monospace".

None of my physical fonts has glyphs for more than 26 characters.
But logical font "monospace" now has glyphs for 52 characters!


Instead of A-Z, 0-9 - imagine different (or overlapping) subsets of the
Unicode set. One fonts might have the math symbols, another the arabic
glyphs, and so on.

This opens an aftermarket for font sets that have compatible-aesthetics
glyphs. I want my cuneiform to be stylistically compatible with my accented
Latin characters. Runes and math symbols should not clash. 'Thorn' and
'Euro' should seem as if drawn by the same hand.
 
F

failure_to

hello

I should mention that I haven¡¦t yet started leaning about applets, AWT
or Swing or anything related to GUI, so for that reason I can¡¦t yet
check these things out via examples



1)

a)
So in essence, at the highest level ( I¡¦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?


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 won¡¦t the text displayed using this logical font be kinda odd
looking, since it will mix characters from two ( potentially )very
different visual styles?




2)
Even though your computer may have hundreds of fonts installed,
with AWT, you can only get at five of them, five chosen by Sun
(unless you use drawString). Sun chooses the physical fonts
from ones it bundles and ones known to be installed with the OS,
and then maps the five logical fonts onto the five chosen
physical ones.

Java maps several physical fonts to one logical font and by doing that
enables visual representation of many characters. So why can¡¦t this
also be done when using AWT?
This way more characters could be displayed ¡K afterall, aren¡¦t most
fonts only 8 bit --> that would suggest that with AWT you can¡¦t
display more 256 characters, at most?!






3)
Modern fonts often come with several encodings. Java just uses
the Unicode encoding.


Meaning even if particular physical font ( call it A ) supports 10
different encodings, java can¡¦t map its logical font onto A unless A
also supports Unicode encoding?
But even if A doesn¡¦t support Unicode encodings, but does support
Ascii, why can't java still map its logical font onto A „³ Afterall,
Unicode encoding uses same code points for first 128 characters as
ascii does?!




4)
RedGrittyBrick wrote:

Lets pretend I am a typographer, I create four monospaced
truetype fonts as follows:

1. RGB-LETR.TTF containing glyphs for characters ABCDEF...XYZ
2. RGB-NUMR.TTF containing glyphs for characters 0123456789
3. RGB-PUNC.TTF containing glyphs for characters ,.:;'`"~
4. RGB-BRKT.TTF containing glyphs for characters ()[]{}<>

Now I install those fonts and edit font.properties to associate
these four physical fonts with the Java logical font
"monospace".

None of my physical fonts has glyphs for more than 26
characters. But logical font "monospace" now has glyphs for 52
characters!

Instead of A-Z, 0-9 - imagine different (or overlapping) subsets
of the Unicode set. One fonts might have the math symbols,
another the arabic glyphs, and so on.


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?






5)
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?!



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?


thank you guys
 
J

Joshua Cranmer

a)
So in essence, at the highest level ( I’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 won’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 can’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)

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

Roedy Green

So in essence, at the highest level ( I??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?

Fonts are only used in AWT or Swing applications/Applets. You can
experiment with a very simple example with just a JLabel in it.

See http://mindprod.com/applet/applets.html
for many examples. You could pick a simple one and strip it down for
your experiments, e.g. the insult generator.

Five was an somewhat arbitrary number. Which font do you think was not
necessary? What is missing?
 
R

Roedy Green

The purpose of mapping multiple fonts to one logical font is to try to
get as much of the Unicode range covered as possible.

Have a look at the possible fonts with
http://mindprod.com/applet/fontshower.html

The stitching together of fonts can be avoided if there is a decent
Unicode supporting font. It would be done primarily to pull in the
Chinese, Arabic etc whose fonts don't look anything like the Latin
ones.
 
W

Wayne

Roedy said:
Java just uses the Unicode encoding and ignores the rest. Read up on
the OpenType format to understand how you can have multiple encodings.

see http://mindprod.com/jgloss/opentype.html

As usual Roedy has answered your questions. But I'd like to take a
stab at drawing a big picture for you:

The term "font" is vague and different people use it in different ways.
For now assume a font an array of tiny graphics created by an artist to
share a particular look, and to "map" to letters, digits, and other
characters. (For the real story search the Internet and visit
Unicode.org, and see the Javadoc API comments for java.awt.Font.)

Type designers knew some things about how humans read text, and
devised "serif" fonts which are letter shapes composed of lines
of varying thickness and small extra bits on the ends of the
strokes. Text of such fonts is much easier to read and pretty
much all books and magazines use serif fonts for body text.
(As should you!)

Text without the extra bits, and often drawn with lines of constant
thickness, are called sans-serif ("sans" is French for "without")
and are used for attention-grabbing such as for headings and captions.

In the early computer era usually a single screen font was built into
terminals. Printers were based on daisy-wheel or line-printer
technology, again that supported a single font. These early
computer screens and printers were limited to drawing
each character in the same sized rectangular block. Such fonts
are called mono-spaced singe all characters take up the same amount
of horizontal space. This leads to an un-even appearance as fat
letters such as 'm' take the same space as skinny letters such as
'i'. As the technology grew more sophisticated computers and printers
became capable of displaying traditional fonts called "proportional".
In these fonts the space between the characters is the same, giving
the text an even appearance. (Are you reading this in a mono-spaced
or proportional font? Look at this to decide: "MMMMMMllllll".)

So a font can be either proportional or mono-spaced. It can have
serifs or be sans-serif. That's four possibilities, but fonts
can have other attributes such as heaviness of the strokes
(bold) or if the letters are straight (roman) or slanted
(italics).

[
Early Unix systems used "X Window" fonts that were named for
each of 14 possible font attributes. You could find a bold,
12 point (one point is roughly 1/72 of an inch) font by doing
a directory listing for: -*-*-bold-*-*-*-12-*-*-*-*-*-*-*
which might find the font file:
-adobe-utopia-bold-r-normal--12-120-75-75-p-70-iso8859-1
Nowadays fonts have names such as "Helvetica" or "Bookman",
which is much less helpful.
]

When Java programmers set a font to use, they typically don't know
what fonts are available on the user's system. So if you guess to
use a font "Ariel" it may or may not be available. However all
home computers ship with a set of fonts standard for that platform.

So for every platform Sun supports, they picked 3 available fonts
(these are the actual fonts installed and are called "physical") and
gave them names you can use in your program. The names are called
"logical font names" since the names reflect the type of the font:
Monospaced" (and usually sans-serif but not necessarily),
"SansSerif" (a proportional font), and "Serif" (also proportional).

So in your program you can chose the system-specific mono-spaced
font for code listings, sans-serif for headings and captions, and
serif for body text. And you don't need to know the real or
"physical" name for that font.

Most home computer systems also have a distinct look and feel to
the pop-up dialog boxes and other system elements (e.g., window
titles). You can use these as well as Sun as kindly defined
the system standard font for dialog boxes as "Dialog" and
"DialogInput" logical font names, so you can make your dialogs
appear native.

Modern AWT does include classes and methods to list all available
fonts installed, so you can look for specific (physical) fonts
and use them if you wish:

import java.awt.*;

public class ShowFonts {
public static void main ( String [] args ) {
Font[] fonts = GraphicsEnvironment.getLocalGraphicsEnvironment()
.getAllFonts();
for ( int i = 0; i < fonts.length; ++i ) {
System.out.print( fonts.getFontName() + " : " );
System.out.print( fonts.getFamily() + " : " );
System.out.println( fonts.getName() );
}
System.out.println( "\n\n\tAvailable Fonts:\n" );
String[] names = GraphicsEnvironment.getLocalGraphicsEnvironment()
.getAvailableFontFamilyNames();
for ( int i = 0; i < names.length; ++i )
System.out.println( names );
} // end of main
}

Still it may be a problem to not know the actual font used by some
logical font name, as different proportional fonts can do line breaks
in different places and mess up the carefully planned appearance of
your application or applet. For this reason the JRE ships with
a set of related fonts called "Lucida". These physical fonts are
available in all Sun JREs and include mono-spaced, Sans-Serif, and
Serif versions. (Look in .../jre/lib/fonts on your system.)
(I don't think Roedy mentioned this in his answer; Roday, as
long as you're updating your font page anyway, remember to
mention this.)

In short Sun as identified three of the fonts on each platform
and given them logical names. You can use one of these three,
the platform-specific dialog fonts (making five logical font
names in all), or pick some actual font name (a physical font)
and hope it is available. It will be if you pick Lucida and
you have a Sun JRE.

As to your last question, remember each font is a collection,
an array or "vector" of graphics known as "glyphs". (It's more
that that really.) Each glyph is identified by a number. For
example a capital "A" glyph in any font that has such a glyph,
is identified by the number 65. Of course anyone can make
their own collection of glyphs as a font, and identify any
glyph with any number. For Java and most software today,
the mapping of numbers to glyphs is the one defined by the
Unicode standard.

Unicode had defined numbers for many thousands of glyphs and it
is unlikely you have a single font file that has every glyph
defined by Unicode. This can be a problem when using logical
font names, since you don't always know if the actual font
has a glyph for all the symbols, arrows, smiley faces, Greek
letters, math and engineering symbols, etc., that you might want
to use. If that is a problem you can find a font that
can display the characters you need with code such as this:

for (Iterator<Font> i = fontList.iterator(); i.hasNext(); ) {
Font f = i.next();
if ( ! f.canDisplay( '\u25B6' ) )
i.remove();
}

(See http://www.hccfl.edu/pollock/Java/UnicodeSymbols.htm for
a sample applet with source that does this.)

There is a whole lot more to the story including ligatures,
kerning, leading, and other fascinating (to me anyway)
facts and history. (Did you know that originally printers
(human ones) traveled with cases containing little wooden or
lead font blocks? The capital letters were used much less
often then the others and were stored in the top or upper
part of the case while the rest were kept in the more
convenient lower part of the case, and that's how we got
the terms lowercase and uppercase letters.)

-Wayne
 
R

RedGrittyBrick

hello

I should mention that I haven’t yet started leaning about applets, AWT
or Swing or anything related to GUI, so for that reason I can’t yet
check these things out via examples

Maybe you should. Playing around with your own code and reading the
documentation is the fastest way to learn.

1)

a)
So in essence, at the highest level ( I’m talking about fonts in
general, not just in Java ) all fonts fall into one of five
categories( based on their visual appearance )?

No. Typographers tend to classify fonts in rather different ways to
programmers.

For example, a Typographer would probably first divide fonts into
decorative fonts and book fonts. Some typographers would divide book
fonts into old style, transitional, modern, sans serif, slab serif, etc.

And for that reason Java also has five logical categories and not six
or four?

No. Two Sun programmers met in a corridor, Bill asked "hey Joe, do you
think we should have three or ten logical fonts in Java?", Joe spilled
his coffee and mumbles "so much *for* that". Bill said "Pardon - four?"
Bill walked back to his desk and wrote down "five". When later asked
"Why five?" Bill claimed he'd analysed 2,347 popular GUI programs and
found that 97.12% of them used no more than five fonts.

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

Thus won’t the text displayed using this logical font be kinda odd
looking, since it will mix characters from two ( potentially )very
different visual styles?

When you mix English and Arabic text, yes there will *unavoidably* be
two visually distinct styles. That's actually the least of your worries.
By careful choice of fonts you might minimise these differences in style
but the important objective is not to have part of the text show up as a
series of small square boxes.

The typographers solution is to spend six months designing a new typeface.

The programmers solution is to spend ten seconds worrying about it
before shrugging and switching to slashdot whilst eating a bagel. Few
programmers care deeply about typography.

2)

Java maps several physical fonts to one logical font and by doing that
enables visual representation of many characters. So why can’t this
also be done when using AWT?

I've never bothered with AWT so this question is uninteresting to me. If
AWT doesn't meet your needs use Swing (or SWT)

This way more characters could be displayed … afterall, aren’t most
fonts only 8 bit

No - but it depends how you are counting them I expect. Run charmap and
have a look on your system. the first font on my PC is Albertus, it
contains an fl ligature at codepoint U+FB02. I went through a few more
before getting bored, they all contained an fl ligature.

--> that would suggest that with AWT you can’t
display more 256 characters, at most?!

Even if it were true, I suspect that some AWT components let you change
fonts part way though text.

3)


Meaning even if particular physical font ( call it A ) supports 10
different encodings, java can’t map its logical font onto A unless A
also supports Unicode encoding?
No.


But even if A doesn’t support Unicode encodings, but does support
Ascii, why can't java still map its logical font onto A 迳 Afterall,
Unicode encoding uses same code points for first 128 characters as
ascii does?!

AFAIK it can. By the way, ASCII is an abbreviation, anyone who cares
about typography ought to capitalise abbreviations!

4)
RedGrittyBrick wrote:

Lets pretend I am a typographer, I create four monospaced
truetype fonts as follows:

1. RGB-LETR.TTF containing glyphs for characters ABCDEF...XYZ
2. RGB-NUMR.TTF containing glyphs for characters 0123456789
3. RGB-PUNC.TTF containing glyphs for characters ,.:;'`"~
4. RGB-BRKT.TTF containing glyphs for characters ()[]{}<>

Now I install those fonts and edit font.properties to associate
these four physical fonts with the Java logical font
"monospace".

None of my physical fonts has glyphs for more than 26
characters. But logical font "monospace" now has glyphs for 52
characters!

Instead of A-Z, 0-9 - imagine different (or overlapping) subsets
of the Unicode set. One fonts might have the math symbols,
another the arabic glyphs, and so on.


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?

Who cares? If you care, try it and see, or read the JLS or the relevant
source code. I'd guess it picks the glyph from the first listed font in
the mapping.

5)

But fonts are involved when you want that UTF-8 file to be displayed?!

Typically you read into an internal character-oriented variable, such as
String. These hold text in (a variant of?) UTF-16. So when reading a
UTF-8 or ISO-8859-1 file the text is converted to UTF-16.

I deduce that Java knows how to use O/S facilities to correctly apply
fonts with any supported encoding to UTF-16 data.

Then how does wordprocessor know which glyph from particular font to
map to which character?

Don't worry about it. If you are writing your wordprocessor in Java then
AFAIK the Java classes take care of those details for you.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top