| ID: | 3698 |
| From: | Gabriel Paubert <pa...@iram.es> |
| Date: | Sat, 18 Jan 2020 16:06:49 +0100 |
| Subject: | Re: [pcb-rnd] Wishlist: improve arc resolution. |
| in-reply-to: | 3697 from ge...@igor2.repo.hu |
| replies: | 3699 from ge...@igor2.repo.hu |
Hi Igor2, On Sat, Jan 18, 2020 at 11:28:19AM +0100, gedau@igor2.repo.hu wrote: > Hi Gabriel, > > On Sat, 18 Jan 2020, Gabriel Paubert wrote: > > > Hi, > > > >The basic reason is that the file format only puts arc endpoint angles > >rounding to the nearest degree, without any decimal place: when you draw > >the line, the accuracy is great, the loss happens when saving the file. > > <snip> > > >I don't know whether this can be solved with a trivial file format > >change, of if this needs much more surgery, and perhaps even a file > >version bump. > > Good catch, thanks! > > Fortunately the data model and the file format both allow floating point > there. The loader loads non-integer angles properly. It's only the write > code that rounds it. So no need to change anything deep. > Ok, thanks. Speaking of angles, I have quite a few "rot = 360.000000" in a large file, about 80. Is it normal that they are not normalized ? Unless I've missed something, they almost all (except one) correspond to the floater associated with a refdes. The last one is a text item on the top silkscreen layer. Anyway, it works, it just looks a bit weird. Note that in this case, the rotation angle is given with 6 decimal digits, which is the default number of decimal digits for %f in C. Why not use the same precision for arcs? It's probably a bit overkill but it should not cause any harm, and all angles/rotations would use the same precision. Best regards, Gabriel
Reply subtree:
3698 Re: [pcb-rnd] Wishlist: improve arc resolution. from Gabriel Paubert <pa...@iram.es>
3699 Re: [pcb-rnd] Wishlist: improve arc resolution. from ge...@igor2.repo.hu