X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Mon, 1 Aug 2016 07:01:24 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: [geda-user] pcb bugreport: poly Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-776141340-1470027684=:7286" Reply-To: geda-user AT delorie DOT com This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-776141340-1470027684=:7286 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Hi all, miloh reported this bug while testing pcb-rnd using pstoedit imported data. A minimal example is attached. If you compile the code with debug enabled (see also: -DNDEBUG), a check catches this. When drawing such a poly, the code asserts when closing it. When loading a file with a poly like that, the code asserts while loading. With debug disabled (a.k.a. normal production code, asserts and checks disabled), it both loads and displays, and it can also be drawn. Using the poly may lead to strange effects, tho. The easiest-to-trigger thing is panning in softwar render mode (lesstif or --disable-gl with gtk): when panning so that some points of the poly is off the screen, it results in strange artifacts. Simply catching such polygons during draw is not enough, because external tools & scripts and old designs can have them any time. I am not sure how this should be solved, but I believe consistent behaviour among debug and no-debug compilation would be better. Proposed solutions: 1. After draw or during load, split up the invalid poly to a set of valid polys. There's code for drawing that does similar things already. Pro: "works as expected" in all cases. Con: a simple load-save cycle may change the file (fixing the polys) 2. on load, stop and report error in non-debug mode; while drawing, remove the polygon if it is invalid. Maybe provide an external tool that can fix up old/external files by splitting up invalid polygons. 3. relax the requirement of non-intersecting polygons everywhere, making it a normal case. This would be a large amount of work, potentially affecting all current exporters. It'd also affect future exporters, probably requiring more efforts to write one as "canonical polygons" can not be expected. Regards, Igor2 --0-776141340-1470027684=:7286 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=self-intersect.pcb Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=self-intersect.pcb IyByZWxlYXNlOiBwY2Itcm5kIDEuMC43DQoNCiMgVG8gcmVhZCBwY2IgZmls ZXMsIHRoZSBwY2IgdmVyc2lvbiAob3IgdGhlIGdpdCBzb3VyY2UgZGF0ZSkg bXVzdCBiZSA+PSB0aGUgZmlsZSB2ZXJzaW9uDQpGaWxlVmVyc2lvblsyMDA3 MDQwN10NCg0KUENCWyIiIDYwMDAwIDUwMDAwXQ0KDQpHcmlkWzI1MDAuMCAw IDAgMV0NCkN1cnNvclswIDAgMC4wMDAwMDBdDQpQb2x5QXJlYVszMTAwLjAw NjIwMF0NClRoZXJtYWxbMC41MDAwMDBdDQpEUkNbMTIwMCA5MDAgMTAwMCA3 MDAgMTUwMCAxMDAwXQ0KRmxhZ3MoIm5hbWVvbnBjYixjbGVhcm5ldyxzbmFw cGluIikNCkdyb3VwcygiMSwzLDQsYzoyLDUsNixzOjc6OCIpDQpTdHlsZXNb IlNpZ25hbCwxMDAwLDc4NzQsMzE1MCwyMDAwOlBvd2VyLDIwMDAsODY2MSwz OTM3LDIwMDA6RmF0LDgwMDAsMTM3ODAsNDcyNCwyNTAwOlNpZy10aWdodCwx MDAwLDY0MDAsMzE1MCwxMjAwIl0NCkF0dHJpYnV0ZSgiUENCOjpncmlkOjp1 bml0IiAibWlsIikNCkF0dHJpYnV0ZSgiUENCOjpjb25mOjplZGl0b3IvYnVm ZmVyX251bWJlciIgIjAiKQ0KTGF5ZXIoMSAiY29tcG9uZW50IikNCigNCglQ b2x5Z29uKCJjbGVhcnBvbHkiKQ0KCSgNCgkJWzEwMDAwIDE3NTAwXSBbMTAw MDAgNDAwMDBdIFszMjUwMCAxNzUwMF0gWzMyNTAwIDQwMDAwXSANCgkpDQop DQpMYXllcigyICJzb2xkZXIiKQ0KKA0KKQ0KTGF5ZXIoMyAiY29tcC1HTkQi KQ0KKA0KKQ0KTGF5ZXIoNCAiY29tcC1wb3dlciIpDQooDQopDQpMYXllcig1 ICJzb2xkLUdORCIpDQooDQopDQpMYXllcig2ICJzb2xkLXBvd2VyIikNCigN CikNCkxheWVyKDcgInNpZ25hbDMiKQ0KKA0KKQ0KTGF5ZXIoOCAib3V0bGlu ZSIpDQooDQopDQpMYXllcig5ICJzaWxrIikNCigNCikNCkxheWVyKDEwICJz aWxrIikNCigNCikNCg== --0-776141340-1470027684=:7286--