[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Investigation into GS8 support of Lout textures

From: K. H. Man
Subject: Investigation into GS8 support of Lout textures
Date: Sat, 10 May 2003 14:15:09 +0800
User-agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130

Hi all,

A few weeks ago I posted a few messages about the known
problem of Ghostscript not being able to handle Lout
textures properly either when displaying on-screen or
when trying to convert the PS file to PDF.

I've taken a look at the GS8.00 source code and below is
some information for anyone interested. Solving it would
probably be a really big job, so I wonder if anyone would
like to take a stab at it... (:-) okay, that is sort of
optimistic) Of course, it would require liaising with
Aladdin people.

Has anyone checked with Aladdin about this? Or, sent them
a test case so that they know about this? If no one has,
I'll wait a few days and check in a bug report with them.

Anyway here are my notes:

The main problem is in the generic driver support (which
is probably used by both the screen and PDF drivers), in
particular, the command list implementation (gxcl.*).

GS drivers talk through a command list (clist) which
provides a well-defined interface for drivers to operate.
Unfortunately, there are some limitations with the

Patterned tiles (Lout textures) unfortunately, are pre-
generated as cached bitmaps by the frontend. The bitmaps
are passed through the command list, and are then indexed
using a hash for efficiency.

Comments in the source code indicate that there are plans
afoot to move tile and halftone rendering to the driver
(backend) but that will take considerable work.

So, what appears in a PDF file is a bitmap. Well, almost.
In order to pass bitmaps through the clist interface, a
bitmap may be compressed using RLE or CFE (CCITTFax). So
for one case of successful PDF file generation I had, the
pattern(texture) object appeared not as operators, but as
a CCITTFax encoded bitmap.

The generic driver handles incoming bitmaps in gxclimag.c
and the actual function that does the job is

This function has quite a few limitations, including
serious depth limitations. It allows only depths of types
1 and a subset of 4, corresponding to 1 bit and 24 bits,
I think. All other image modes end up with a call to
gx_default_begin_typed_image which breaks the image up
into small rectangles or pixmaps. Thus, on other attempts
at converting textured Lout PS output to PDF, Ghostscript
outputs tons of lines that draws a little rectangle each.
Most of the time, ps2pdf will fail while doing this.

On-screen display of patterns(texture) issue is also
probably due to the combination of the driver interface
design and the limitations of the bitmap renderer.

Full pattern support in Ghostscript would ideally require
(1) tile rendering to be performed in the backend,
(2) a redesign of the backend driver interface, and
(3) better bitmap rendering to avoid cutting up bitmaps.

That's a really big job, but I think I'll check and see
if the Aladdin people have a timeline for this. Still, I
don't think we can hope for full pattern support in the
near future.

Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia... fiddling with Open Source,
bits and pieces at http://www.geocities.com/keinhong/
"Verify range to target, one ping only..." - Marko Ramius

reply via email to

[Prev in Thread] Current Thread [Next in Thread]