GNOME Bugzilla – Bug 144394
Dia export and anti-alias view badly broken
Last modified: 2006-11-25 20:41:02 UTC
A Debian user reported the following bug: ============================================================================== As per the subject... please see these examples. Here is the .dia file: http://bum.net/Diagram4.dia A screenshot of it displayed in edit mode: http://bum.net/snapshot1.png Now I switch on View -> AntiAlias: http://bum.net/snapshot2.png And after I File -> Export: http://bum.net/proposed.png ============================================================================== See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=254382
At least confirmed ...
Created attachment 29405 [details] Tarball with the reporter's files
Can't reproduce any longer with current cvs. Maybe this got fixed by cleaning the memory corruption/missue in the basic renderer ? http://cvs.gnome.org/viewcvs/dia/lib/diarenderer.c?r1=1.13&r2=1.14 2004-09-19 Hans Breuer <hans@breuer.org> * lib/diarenderer.c : don't try to draw lines which are so much degenerated that their point count became negative, fixes bug #148139
Hm, bad news from this end, I'm afraid. (I'm the original Debian bug reporter) With today's CVS, I get the same fault as with 0.94 - i.e. the rendering is even worse than 0.93 - even the non-antialiased view is badly corrupted. This is all still working with the same Diagram4.dia sample file at the top of this page Edit mode: http://bum.net/snapshot-cvsedit.png Edit more with AA on: http://bum.net/snapshot-cvseditaa.png Exported PNG: http://bum.net/Diagram4.png Cheers, Gavin.
Please attach files to the bug instead of linking to them. I got File not found with the above links.
With 0.95-pre3 there is still a big difference in whether the prodivided .dia file is viewed in normal or anti-aliased mode
I can see the difference within dia (0.95-pre3) too. Means: the not-antialised diagram seems messed up. But exports to eps and svg look good (=like the antialiased in dia) in evince and inkscape -no matter wheter antialiased was turned on in dia before exporting.
Notes from chat session: [when exporting] <wen> 144394: i get output like Saving line: Handle 0 (0x9433494) on object 0x94333e0 has po s 19,392500, 6,570840, <wen> but its CP 0x943330c of object 0x9432d98 has pos 19,392506, 6,570844 <wen> Saving line: Handle 0 (0x943392c) on object 0x9433878 has pos 10,542500, 9,17084 0, <larsrc> That's the UML class sanity check output. Sounds a lot like the diagram is messed up, then. <wen> Bug 144394: The exports look good in inkscape (svg) and evince (eps). No matter whether i did antialiasing in dia before exporting, the exported file looks like the antialiased, "sane" dia-rendering
Actually, I dont get the error messages quoted above not when exporting but when turning on antialiasing. Here the complete output: Saving line: Handle 0 (0x941e104) on object 0x941e050 has pos 19,392500, 6,570840, but its CP 0x941df7c of object 0x941d9c0 has pos 19,392506, 6,570844 Saving line: Handle 0 (0x941e2b4) on object 0x941e200 has pos 10,542500, 9,170840, but its CP 0x941d8ec of object 0x941d580 has pos 10,542506, 9,170844 Saving line: Handle 0 (0x941f664) on object 0x941f5b0 has pos 14,350000, 18,000000, but its CP 0x941eed8 of object 0x941ed60 has pos 14,350000, 18,000000 Saving line: Handle 0 (0x941fdcc) on object 0x941fd18 has pos 14,350000, 18,000000, but its CP 0x941eed8 of object 0x941ed60 has pos 14,350000, 18,000000 Saving line: Handle 0 (0x94233c4) on object 0x9423310 has pos 1,625680, 23,745700, but its CP 0x9422264 of object 0x9422430 has pos 1,625684, 23,745700 Saving line: Handle 1 (0x94233e4) on object 0x9423310 has pos 1,768320, 6,725430, but its CP 0x9423214 of object 0x9422e90 has pos 1,768316, 6,725427 Saving line: Handle 0 (0x94235a4) on object 0x94234f0 has pos 10,346300, 4,563010, but its CP 0x941d954 of object 0x941d580 has pos 10,346274, 4,563006 Saving line: Handle 1 (0x94235c4) on object 0x94234f0 has pos 5,076730, 4,071640, but its CP 0x9423248 of object 0x9422e90 has pos 5,076726, 4,071644 Saving line: Handle 0 (0x94249cc) on object 0x9424918 has pos 5,076730, 4,071640, but its CP 0x9423248 of object 0x9422e90 has pos 5,076726, 4,071644 Saving line: Handle 1 (0x94249ec) on object 0x9424918 has pos 16,812000, 4,226050, but its CP 0x941df48 of object 0x941d9c0 has pos 16,812012, 4,226051 Best regards, wen
There is a $US100.00 prize to fix this. Good luck!
I am pleased to announce that the prize is now $US200.00. See the mailing list for details.
Created attachment 75843 [details] [review] Function calculate_arrow_point did not initialize move_arrow and move_line in the case of narrow arrow (arrow->width < 0.0000001)
The patch looks ok to apply, but the bug fixed does not explain the wrong rendering from "Diagram4.dia" atached above. The arrow size is set to 0.01 but the bug fixed would only be triggered with a much lower arrow->width (0.0000001).
Vadim, I've you're interested in the USD 200 bounty on the bug, please also fix the cases that are not covered yet by your patch (say, arrows on arcs or beziers). Additional information from Lars: I've been hacking on a fix that will "sanitize" arrow heads either on load time or on display time -- I'm leaning towards load time now, as that would help in batch convert, too. I'd like to know how that arrow head was made, though.
(In reply to comment #13) > The patch looks ok to apply, but the bug fixed does not explain the wrong > rendering from "Diagram4.dia" atached above. The arrow size is set to 0.01 but > the bug fixed would only be triggered with a much lower arrow->width > (0.0000001). 0.01 is showed in user interface. but in .dia file you can see ... <dia:attribute name="end_arrow_width"> <dia:real val="0"/> </dia:attribute> ... <dia:attribute name="end_arrow_width"> <dia:real val="2.77556e-17"/> </dia:attribute> ...
(In reply to comment #14) > Vadim, > I've you're interested in the USD 200 bounty on the bug, please > also fix the cases that are not covered yet by your patch > (say, arrows on arcs or beziers). My patch affect to drawing of arrows, so it must cover arrows on arcs, beziers, etc. > Additional information from Lars: > I've been hacking on a fix that will "sanitize" arrow heads either on load > time or on display time -- I'm leaning towards load time now, as that > would help in batch convert, too. I'd like to know how that arrow head > was made, though. By way, python scripts can create arrows with tiny width? Please pay attention to my patchs: http://bugzilla.gnome.org/attachment.cgi?id=74925&action=diff http://bugzilla.gnome.org/attachment.cgi?id=71380&action=diff They appeared useful to my work in dia, and as I suppose, can be useful someone yet.
Created attachment 76135 [details] diagram with narrow arrows
Your patch does indeed fix the problem, but using a ?: in a switch is not pretty. Better to take out the arrow type and set it to ARROW_NONE in the appropriate case.
Created attachment 76751 [details] [review] Change of patch #75843 in accordance with recommendation of Lars Clausen I suppose that a "sanitization" of information is not good idea, as it supposes the change of the information not authorized by the user. Especially as in this case "sanitization" is used not for the elimination of a bug, but for its mask.
I've committed a slight variation on your fix that doesn't use :? and also checks on the length, as well as Pontus Pihlgren's fix in the loader. This bug is now thoroughly fixed.