FW: PCLRenderer

[Art Welch]

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:[EMAIL PROTECTED]]
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) 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