Fonts and Printing

[Tarlika Elisabeth Schmitz]

Hello,

Scenario:
I am developing a Java application which is to run both on Windoze and
Linux PCs. I have designed a report [using JasperReports] specifying the
fonts for the report fields ("Times New Roman" and "Arial").

The print-out looks fine on the Windows machine where the reports were
originally designed. However, on the Debian Linux PC the fonts aren't
found although they are installed.

Question:
a) Where and how are the fonts picked up from?
b) Can the fonts be deployed with the application?
--


Regards/Gruß,

Tarlika Elisabeth Schmitz

 

[Thomas Weidenfeller]

The print-out looks fine on the Windows machine where the reports were
originally designed. However, on the Debian Linux PC the fonts aren't
found although they are installed.

Just a few days ago I have ranted on comp.lang.java.gui about the broken
Java printing system. This was one of my complaints.

Question:
a) Where and how are the fonts picked up from?

AFAIK they are not picked up at all. Printing on Unix (I didn't check
for Linux) uses a PostScript generator build-in into Java. That
generator maps the fonts you want to use to one of the 35 default
PostScript fonts. But, there is no way to enumerate the printer (or
printing system) fonts in Java, just the GUI fonts (which are not used
here ...).

b) Can the fonts be deployed with the application?

Yes, but it doesn't help unless you change the way you print. You can
deliver TrueType fonts, and with Java 1.5 also Type 1, fonts, but the
printing system doesn't use them. At least I haven't seen the printing
system using them. What you can do is one of the following:

1. A hack:

Don't render your page to the printing Graphics directly. Instead,
render them to a BufferedImage, with sufficient resolution. Also turn
anti-aliasing rendering hints on. That way you will use the system's GUI
rasterizer or Java's build in rasterizer (T2K from typesolutions). T2K
isn't too great. Until recently the version build into Java didn't use
hints at all.

Once you have rendered such a BufferdImage, draw it onto the printing
Graphics.

Note: This will require some memory in Java, as well as in the printer.
SOHO type printers might not have enough memory to hold such a complete
page-as-image and might barf.

2. Consider using the "yet another new" javax.print API

Directly create PostScript, look up a PostScript doc flavor and use that
for writing your PostScript. You can download fonts as part of
PostScript. Have a backup plan in place in case your application runs on
a system/VM combination that doesn't provide a PostScript doc flavor.

/Thomas

 

[Tarlika Elisabeth Schmitz]

Hello Thomas,
Thank you for your in-depth reply. I had been worried that my questions
might have been of the dummy type but as your reply shows there is much
more to it than I care for.
At last I have come across some platform differences; so much for "Write
once, run anywhere".

AFAIK they are not picked up at all. Printing on Unix (I didn't check
for Linux) uses a PostScript generator build-in into Java. That

As I mentioned before, I am not actually programming the printing myself
- I use JasperReports. What made me think that the System fonts must be
picked up somehow was the fact that the GUI report designer offers a
list with all the fonts installed on my Win2K machine. In fact, I just
chose a more exotic font in the design and it is really picked up at
runtime. On Windows it must be picked up from c:\winnt\fonts.
I presumed that there must be a similar mechanism on Linux. But then
again different Linux flavours might handle the fonts differently, not
to mention what different VMs might do.
(I use Blackdown, which is supposedly a Sun clone; Sun's own runtime
won't install on Debian Linux)

What you can do is one of the following:
2. Consider using the "yet another new" javax.print API

This isn't really within my control as the printing is done by
JasperReports. I suppose I shall have to consult their mailing list to
see what other people's experiences are. It's one of the most widely
used open source report generators, so there should be some Linux users
out there.


--


Regards/Gruß,

Tarlika Elisabeth Schmitz

 

[Thomas Weidenfeller]

As I mentioned before, I am not actually programming the printing myself
- I use JasperReports. What made me think that the System fonts must be
picked up somehow was the fact that the GUI report designer offers a
list with all the fonts installed on my Win2K machine. In fact, I just
chose a more exotic font in the design and it is really picked up at
runtime. On Windows it must be picked up from c:\winnt\fonts.

Printing in Java on Windows works different than printing on Unix/Linux.
Printing on Windows uses the Windows GDI API. That Windows API is
capable of using Windows GUI fonts, so on Windows you don't have a
difference in the list of available fonts. AFAIK windows either uses a
printer's build in rasterizer or uses the same rasterizer for printing
than for GUI display. Windows printing can also download GUI fonts to a
printer if they are not available on the printer. So from a Java point
of view, almost all GUI fonts are available for printing.

I presumed that there must be a similar mechanism on Linux.

Traditionally Unix printing and Unix GUI (X11) are two completely
separate systems. Traditional Unix printing doesn't even allow to query
printer type, capabilities or fonts. A Unix application had to have a
build-in driver for a particular printer, much like it was the case in
ancient DOS. And a user had to chose the right driver before printing.

Over the time two particular printer types became common under Unix:
PostScript and/or HP PCL capable printers. And with the availability of
the ghostscript RIP PostScript became the most common format.

So Sun's idea of generating PostScript when printing from Java on Unix
is a logical way of doing things on Unix. Only that they forgot to
provide basic support, like being able to enumerate the (virtual)
printer fonts or get their font metric directly.

There seems to be a strange idea among the Java team that printing is
just the same as drawing a GUI and that the GUI API is sufficient for
printing, too. Maybe due to the NeWS background.

But then
again different Linux flavours might handle the fonts differently, not
to mention what different VMs might do.

All the Unix/Linux VMs which I have seen (certainly there are more) did
generate PostScript. So using a PostScript font name should give you the
same results on these VMs. PostScript font names should also more or
less work on Windows, since Windows maps PostScript font names to
similar (but not identical) Windows fonts (e.g. Helvetica to Arial).

/Thomas

 

[Tarlika Elisabeth Schmitz]

Hello Thomas,

Traditionally Unix printing and Unix GUI (X11) are two completely
separate systems. Traditional Unix printing doesn't even allow to query
printer type, capabilities or fonts. A Unix application had to have a
build-in driver for a particular printer, much like it was the case in
ancient DOS. And a user had to chose the right driver before printing.

....

Thank you for shedding light on this issue.

--


Regards/Gruß,

Tarlika