[gs-code-review] 688177 Eliminate the 64 bit pixel size limit

[Leonardo]

Dan,

The main advantage of Igor's approach is to weeken the constraint forever,
so that we'll not need to redo this effort after half year.

One uneasy thing of changing to a non-integer type
is to find out places of color index comparison.
The compiler may not find them automatically.
There are few ones in the graphics library code,
and likely they all are already found.
However customer's devices may need some debugging.

By another hand, the numerous changes through entire graphics library
don't look as a disadvantage. Now color index operations
are encoded with C language operations, but the encoding is not 1-to-1.
A problem happens with gx_no_color_index, you know.
In Igor's code an absence of an index is a NULL pointer,
and it is different than any existing color index, which
requires a non-NULL pointer. Therefore such change
would eliminate the old hack, and it should be considered
as a progression.

Igor's approach requires us to write an instruction for developers
how to upgrade code of their devices. It should start with
running a compiler with the old code and get a list of errors,
which points to lines, which to be changed.

Besides that, you looks to take a big care of DeviceN process color model,
and a small care about DeviceN colors in documents.
Your patch sets a constraint for document designers
not to use mixes of multiple inks. However such mix
may unintentionally appear in shadings : for example, if a tensor shading
uses 4 source colors of 4 inks each, in the middle of the
shading will use up to 16 inks, which overflows your constraint.

Leo.



----- Original Message ----- 
From: "Dan Coby" <dan.coby at artifex.com>
To: "Igor V. Melichev" <igor.melichev at artifex.com>; "Gs-Code-Review" 
<gs-code-review at ghostscript.com>
Cc: "Miles Jones" <miles.jones at artifex.com>
Sent: Thursday, September 01, 2005 12:29 AM
Subject: RE: [gs-code-review] 688177 Eliminate the 64 bit pixel size limit 
(xefitra)


>
> Igor,
>
> I am not sure about how your scheme works.  I did look at the URL that you
> gave in your email and also at the patches that you posted to the bug 
> 688177
> bug report.  However I am still not sure about what you are doing.  If I 
> am
> wrong about what you are doing then let me know.
>
> It looks like you are changing a gx_color_index to be a non integer type. 
> If
> so then this is both good and bad.  The major advantage is that once that 
> change
> is made, then it will probably be fairly easy to support things like a 
> very
> large number of colorants.  The major disadvantages of using a non integer 
> type
> are that changes have to be made throughout the entire graphics library 
> and all
> of the current device drivers.  This is a very large effort.  Besides 
> changing
> every reference to a gx_color_index type variable, there are issues with 
> memory
> management for things like changing raster buffer sizes as spot colorants 
> are
> found while processing a file.  This sort of change is also likely to make
> the general operation of the graphics library slower.  I do see that you 
> seem
> to have a scheme which allows switching between an integer an non integer 
> types
> at compile time.  This does eliminate some worries but it also creates 
> other
> issues about testing the different versions.
>
> My first email gave a list of the advantages and disadvantages of my 
> scheme.
> I would like to emphasize the advantages of this method include that it is 
> quick
> to implement, it does support 64 (or more) colorants and it does not 
> affect the
> majority of the graphics library or any other device.  This makes issues 
> about
> support of customer and GPL devices much simpler and the likelihood of 
> introducing
> bugs into the graphics library is eliminated.
>
>
> Dan
>
>
> -----Original Message-----
> From: gs-code-review-bounces at ghostscript.com
> [mailto:gs-code-review-bounces at ghostscript.com]On Behalf Of Igor V.
> Melichev
> Sent: Wednesday, August 31, 2005 6:46 AM
> To: Gs-Code-Review; dan.coby at artifex.com
> Cc: Miles Jones
> Subject: Re: [gs-code-review] 688177 Eliminate the 64 bit pixel size
> limit
>
>
> Dan,
>
> Your approach changes a very strong restriction to a strong one.
> IMO there is a way to change it to a very weak one,
> at least for the kernel of the graphics library :
>
>     color components <= 64
>     color component bits <= 16
>
> See gxcindex.h Revision: 1.7.2.2, Mon Jun 20 22:47:12 2005 UTC (2 months, 
> 1
> week ago) by igor
> http://cvs.ghostscript.com/cgi-bin/viewcvs.cgi/cvs/ghostscript/gs/src/gxcindex.h?rev=1.7.2.2&only_with_tag=COLOR_INDEX_2_64&view=log
>
> Igor.
>
> ----- Original Message -----
> From: "Dan Coby" <dan.coby at artifex.com>
> To: "Gs-Code-Review" <gs-code-review at ghostscript.com>
> Sent: Wednesday, August 31, 2005 11:25 AM
> Subject: [gs-code-review] 688177 Eliminate the 64 bit pixel size limit
>
> [...skipped...]
>
>>  Number of non zero components    Index bits Bits per component
>> 0 to 5    24      8
>>    6    16    8
>>    7     8    8
>>    8          8    7
>>    9     8    6
>>   10     8    5
>>   11     8    5
>>   12     8    4
>>   13     8    4
>>   14     8    4
>>     More than 14 Not enclosable
>
> _______________________________________________
> gs-code-review mailing list
> gs-code-review at ghostscript.com
> http://www.ghostscript.com/mailman/listinfo/gs-code-review
>
>