RE: Another patch with a massive renderingdifference.

Igor,

I have patch that I would like to check into CVS.  This change
affects the size of a halftoning pattern.  This change causes
1597 'regressions'.  Actually these are progressions.  After
checking in this change, I need to update the baselines for
331 files.  This only leaves 78 files that I do not need to
change the baseline.

My question are:  How do I check in my change and update the
baselines without possibly losing a real regression caused
by all of the current outstanding regressions?  When will I
be able to check in my changes safely?


Dan


-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Igor V.
Melichev
Sent: Saturday, November 01, 2003 12:17 AM
To: Ray Johnston
Cc: Miles Jones; Jack Moffitt; [email protected]
Subject: Re: [gs-code-review] Another patch with a massive
renderingdifference.


Ray,

> From: "Ray Johnston" <[email protected]>
> To: "Igor V. Melichev" <[email protected]>
> Cc: "Miles Jones" <[email protected]>; "Jack Moffitt"
<[email protected]>; <[email protected]>
> Sent: Saturday, November 01, 2003 2:12 AM
> Subject: Re: [gs-code-review] Another patch with a massive
renderingdifference.


>  Your committment of this patch
> on top of the pending regressions greatly complicates his effort.

I'm unclear what does it complicate.
The patches were committed in different days.
There were 1 nightly checkpoint between then.
To analyze differences one should use an appropriate checkout.

> Once again, before the previous regressions have been examined


> In this case it does not make sense that Courier vs. NimbusMonL-Regu
> in the PDF file would cause *ANY* regression difference since the
> same font (NimbusMonL-Regu) is used to render the PDF and the PS,
> thus the raster image should not change.

PDF is not so simple.
With embedded fonts it provides Widths array.
With standard fonts it does not.
The new revision recognize Courier as a standard font and does not embed it.
Therefore there is no Widths.
Therefore lsb from the font is used when rasterizing the PDF.
With embedded fonts the lsb first is converted by pdfwrite to 1000 unit
scale,
then the rasteriser converts it back to design units, then to device units.
Therefore the results can't be identical.

In any case, since the new revision doesn't embed fonts,
it appears closer to PS-->raster, i.e. it is a progression.
I've said it in my announcement.

As to the old revisions, I intend to open a bug for tracking the case
of inprecise Widths. It was on 2am of my local time,
and I decided to delay it for the next day.
I don't think that I should report such minor things whenever they occure.

> To what do you attribute the massive expected regressions for this
> patch?

I've run a regression testing on my comp before committing.
It reported the differences.
I've checked many arbitrary choosen ones,
and saw it is a progression. I informed stuff about that.

> Jack is only 1/2 time and
> also does not have your insight into the nature of expected
> differences in order to verify that differences are either trivial
> or are improvements.

I believe that I can find a manpower for this duty for $1000/month.
Could this help ?

Igor.


_______________________________________________
gs-code-review mailing list
[email protected]
http://www.ghostscript.com/mailman/listinfo/gs-code-review