Re[2]: [cgmo-webcgm] miter limit

[Benoit Bezaire <benoit@itedo.com>]

I'm not sure if an erratum should be pursued. Last time I checked GDI+ had support for the CGM 1999 wording. I think the key thing is to loosen up the rendering criteria in WebCGM 2.0. 

I'm not objecting to an erratum, I just suspect there are better things to do.

-- 

Regards,

 Benoit   mailto:benoit@itedo.com

This e-mail and any attachments are confidential and may be protected by legal privilege. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you for your cooperation. 

Wednesday, September 13, 2006, 7:21:00 PM, Lofton Henderson wrote:

>

Excellent, thanks Forrest.  I think this should put the question to rest.  

Rob (in off-list dialog amongst implementors) verified that the documented PostScript algorithm is the same as the documented GDI algorithm -- revert to bevel.  Forrest verifies that GDI implemenation matches GDI documentation.  Forrest also points out a wrinkle that PS and GDI differ in their *default* values ('miter' join style set, but no explicit miter limit set), and both differ from the CGM:1999 default that is essentially "no limit".

So CGM:1999 algorithm ("truncate at the limit") differed from both ("revert to bevel"), and that is what we corrected in the WebCGM 2.0 text.  WebCGM 2.0 issue closed.  (Agreed?)

QUESTION:  do people agree that it is a good idea to pursue a CGM:1999 erratum?  

I think it is an error.  Although this stuff was written more than a dozen years ago, I can't imagine that the CGM people intended, after borrowing the concept from PostScript, to define an algorithm that had no hardware support (in PS, GDI, probably others) and would be expensive to implement.  To my knowledge, no one has implemented the CGM:1999 documented algorithm.  

-Lofton.

At 04:46 PM 9/13/2006 -0500, Forrest Carpenter wrote:

All,

After digging into this, I believe the Widows GDI and postscript are the same when the values for miter limit are actually set in the postscript file and set in the GDI rendering. The reason we were not drawing the correct 170 join under the default setting was we were not actually setting the miter value in the GDI. It turns out the default value for miter limit in GDI is 10 and the default value for miter limit in postscript is 14. A value of 10 will result in a join bevel at 170 and a value of 14 will result in a miter join at 170. If implementers set the value for miter limit in the GDI code the result will be correct. The current default for miter limit in CGM is 32767. If we can change this to match the postscript value of 14 we should. High values of miter limit can result in spikes all over the place in some CGM files. I have attached a PNG file we generated from our implementation.

Regards,

Forrest