FW: PCLRenderer

[Art Welch <ar...@EASTPOINT.COM>]

I sent this directly to Yvonne, but I have received error messages from
materna.de indicating that it may not have gone through. Maybe it will be
more successful through the FOP list... and it could be interesting to
others using the PCLRenderer.
 
Art
 
-----Original Message-----
From: Art Welch 
Sent: Friday, April 26, 2002 12:09 PM
To: 'Moebius, Yvonne'
Subject: RE: PCLRenderer


Hi Yvonne,
 
Unfortunately trying to pass control codes (either for font changes or image
data) is not likely to work very well. What I have done in the past when I
wanted a different font was to use one of the existing fonts that had
metrics similar to the font I wanted. This would allow the layout to work.
Then postprocess the PCL output and do a search and replace on the control
codes. This of course would be problematic if you want to use several
non-standard fonts. In my case I just needed to use alternate fonts for
Helvetica and Times. The alternates had almost identical metrics. This
worked quite well.
 
If you are open to building your own custom version of FOP. The PCLRenderer
uses a function to map the font names to PCL control codes. You could add
your fonts to this function. This may work. I am assuming that the fonts are
resident in the printer and you have added the fonts to FOP. At one time I
was actually thinking that I would add all the standard PCL mappings to this
function. If you do this, I would be happy to commit your changes to CVS. Of
course the larger case includes support for fonts not resident on the
printer. Supporting font download looked a bit icky. Since the font names
can be a bit fussy, another option may be to add some kind of mapping (FOP
font to printer font). But this all starts getting complex.
 
Dithering is a technique to increase the apparent color depth of an image.
Basically you define a region of the image and use the available colors to
visually approximate a greater range of colors. The simplest way to do this
is to use pixel expansion to do this - essentially resolution is traded for
color depth. For example if you wanted to represent four shades of gray on a
device that can only set individual pixels to black or white you could use
four pixels to represent each source image pixel (doubling the size of the
image). The four shades could look like this ('.'=off, '#'=on):
 
. .
. .
 
. #
# .
 
. #
# #
 
# #
# #
 
This is the idea anyway. A simple mapping does not really give the best
results. There are sophisticated algorithms that produce much better
results. To complicate things, the algorithm that produces the best visual
results varies with the source image, resolutions, color depths, etc. I
would use an image processing application to translate the images. There may
be functionality in the JDK to do this. I am on a "graphically challenged"
platform, so generally avoid the graphics APIs.
 
I hope this helps,
Art

-----Original Message-----
From: Moebius, Yvonne [mailto:Yvonne.Moebius@materna.de]
Sent: Thursday, April 25, 2002 3:04 AM
To: Art Welch
Subject: PCLRenderer


Hello Art,
 
I am not sure if I should send this e-mail to the FOP mailing list, but as
you offered me to inform you about my main problems with the PCLRenderer, I
am writing to you directly.
 
The most important thing for me is to include fonts, which are not included
in the Adobe base 14 font package. But  the limitation is that with the
PCLRenderer only the original fonts built into FOP are supported. 
 
As long as the PCLRenderer has got this limitation, I am thinking of a kind
of workaround, to tell the printer which fonts I want to use. I tried to
send the font information as PCL commands to my printer as unparsed CDATA.
But these font information contain the control character <ESC>, and this is
not allowed in CDATA.
Maybe you have got any indeas for a better workaround?
 
The other thing I find onerous are the <fo:external-graphic>s, they only
appear in black and white, and I am missing the grey shades. On the output
format site ( http://xml.apache.org/fop/output.html
<http://xml.apache.org/fop/output.html> ) is written :"If you need to print
a non-monochrome image you should dither it first. " I don't know excectly
what is meant with "dither" in this context. Does it mean that there is any
way to make the grey shades of my image visible?
 
In this case, too, I am thinking of including my images as unparsed PCL
commands, but again there is the problem with the control characters.
 
I would be thankful if you have any ideas of how to work around these
problems, or if you can tell me if it will be possible to remove these
limitations.
 
Bye, Yvonne