[Gs-devel] RE: refine MDRC patch

[mpsuzuki at hiroshima-u.ac.jp]

Dear Mr. Igor,

>>However, of course, I'm not sure if this is good solution.
>>Do you have any good idea?

(method 1)
>If I write this from scratch, I would do in reverse order.
>First I would compare 2 neighbor ranges and find maximal common prefix.
>Then I take all consecutive ranges, which correspond to the prefix,
>and generate keys for them. This requires 1 range lookahead.

(method 2)
>This algorithm is not optimal also. A better result may be obtained
>if consider trees of prefixes. Actually there are 3 trees :

[detailed explanation is omitted, sorry]

>But I believe that all this is too academic and overcomplicated
>for our simple problem, so as simple lookahead would give acceptable
>result.

Much thanks for your comment. I think, the former method
(making prefix and merge by lookaheaded range) could be
implemented without changing the interface.
The later method sounds great, but, to implement it well,
the internal format of CMap should be reconsidered, I think.

Although I think the later method improves CMap handler greatly,
but the indepth change makes me hesitate.
If I rewrite the algorithm totally, I want to follow
the former method. How do you think of?

>Of cause, I can easy construct one, on which your algorithm fails
>(it can exceed 64K limitation for key string length, if CMap uses
>3-byte codes), but this is not the issue. The criterion is 3d party
>CMaps to run effectively.

I was not aware of the problem, please let me know detail.
As far as possible, I have to fix the bug or print warning for
opened bug. I understood your pointing out as following:

	For the range specification using 3-byte codes,
	there can be 128 (or more) ranges with same first byte.
	Aslike:
	<000101> <000101> 1
	<000102> <000102> 2
	...
	<00FFFF> <00FFFF> ?

	My algorithm tried to merge all of them,
	because they have same prefix <00>.
	The string collecting each keys exceeds 64k limitation.

Hmm, now I think I should rewrite prefix/key generator,
following to your idea.

Soon I will make quick-fixed version of previous MDRC and publish
it in this mailinglist, but I don't ask the official adoption of it.

>--------------------------------------------------------------------

>But I never saw "cidrange" or "bfrange" except your /Z example
>(being constructed artificially, and tested on Solaris only).
>Do you have any 3d party CMaps with multi-dimensional
>"cidrange" or "bfrange" ?

No, I don't know any example using multi-dimensional
"cidrange" or "bfrange".

>For "codespacerange" we don't need to compute "relpos", right ?

Yes, "codespacerange" does not require.

>Next, the policy of Artifex is to follow Adobe specs,
>and enhance our product with compatibility to other systems
>when it is useful for users. Since Adobe specs don't explain
>about multi-dimensional cidranges, your proposal looks as
>an enhancement with a feature of Solaris.
>Are you sure that this feature is compatible with other systems ?
>For instance, what happens if you example runs on Adobe Photoshop ?

>I would be happy if you run your tests with other Adobe's products:
>Photoshop, Acrobat Reader, Distiller.

Hmmm, I thought it's Adobe-proper behaviour and implemented it.
But I agree with your pointing out: "Solaris" is not suitable
example, because it's based PosScript Level 2 plus may SMI's
enhancements.

Unfortunately, I don't have Adobe PhotoShop, I cannot check on it.
If I could find same behaviour on PS printers with OEM rasterizer
by Adobe (around me, there are Level 2 & 3), it can be some proof?

Of course, I appreciate the attitude to keep the compatibility
with Adobe official PostScript implementation, so if "relpos"
is incompatible with Adobe, I must remove it.

>>However, I could not find explicit specification for such case
>>in Adobe documentations, so I wonder this is what Adobe thinks
>>"should be so".
>
>Another alternative is : Adobe thinks "this should never happen".

Ah, I missed this possibility.

Best Wishes,
mpsuzuki