[gs-code-review] RE: stefan's bittagging patch

[Dan Coby]

Ralph,

Since your purpose is bring the GS and PCL branches together, I
have no objection to making this commit.  Committing this stuff
is probably the quickest and easiest path toward a single tree.

There are several things that I do not like.  I think that they
can be corrected after you commit this stuff.

1)  I still have to finish 688638 'Make ROPs and overprinting
compatible'.  This is key to resolving your questions about the
various map_color_rgb routines.  Obviously this is critical for a
language switch build which needs to support both PCL ROPs and
PS/PDF overprinting.  I am bumping this to the top of my queue.

2)  Someone decided to define gs_bitrgbtags_device with a giant
structure initialization instead of using the various device
macros.  I do not know why.  It makes for very fragile code since
if someone adds a field to the gs_device or gs_prn_device structures,
then the initialization will fail.  (Fortunately I think that it
will be a compiler failure instead of silently putting the wrong
data into device fields.)  I realize the device macros are
pretty unobvious to use.  However this structure initialization is
even worse since there are not even comments indicating what fields
are being initialized.  Instead there is over one hundred lines
of obscure numbers without any explanation.  This is particularly bad
since this is supposed to be an example of how to do device level
object tagging.

3.  I am not really thrilled about some of the hacks for detecting
text versus vectors in the object tagging logic.  Igor has already
commented on this issue.  I am enclosing a diff for the relevant
changes that I made for custom color processing and switchable CRDs
(two other places that also want to make color processing decisions
based upon the object tag.

Note:  I used the term 'object type' in my code instead of Stefan's
term 'object tag'.  Stefan's term is probably better since 'object type'
is too generic.  I will change my nomenclature to match his.

Basically I set the object tag before setting the device color
when processing an object.  Thus it is being done a little higher
in the processing chain than Stefan's version.  I believe that this
eliminates the guess work required about text versus vectors.  It
works with all of the test files that I have tried.  It even found
some strange cases in the altona test suites.  (The custom color
processing code simplifies testing since one of its demos changes
all text to red, all images to green, and all vectors/fills to blue.
Thus you can look at the object type on the display.)


I suggest that we proceed as follows:
a)  You commit your patch for Stefan's object tagging.
b)  I modify my custom color processing logic to use Stefan's
nomenclature and also to include his BITTAG global value.
c)  I commit my changes which pulls Stefan's version of setting the
object tag and replaces it with mine.
d)  I straighten out 688638 and commit this fix.

I am hopeful that I only have to do my commits to a single tree (gs head).


Dan


-----Original Message-----
From: Ralph Giles [mailto:ralph.giles at artifex.com]
Sent: Monday, August 28, 2006 11:11 PM
To: dan.coby at artifex.com
Cc: gs-code-review at ghostscript.com
Subject: stefan's bittagging patch


Dan,

This is (I hope!) the complete patch for stefan's bittagging work 
from the GhostPCL branch. I've not tested it or resolved the conflict 
with your commit in r6702 as a fix for 688638.

This patch is also missing makefile dependency updates for the new 
headers.

If you want to do that and apply to gs trunk, that would be great. If 
you don't have time let me know and I'll do it.

 -r

-------------- next part --------------
A non-text attachment was scrubbed...
Name: object_tag.dif
Type: application/octet-stream
Size: 3944 bytes
Desc: not available
Url : http://ghostscript.com/pipermail/gs-code-review/attachments/20060829/5323faf1/object_tag.obj