Re: [Kicad-developers] Symbol library code changes

Thanks! Just to show I wasn’t making it up, here is a screen grab of what happens when I click the link you provided initially. I edited the link to remove the period (https://docs.google.com/document/d/1lyL_8FWZRouMkwqLiIt84rd2Htg4v1vz8_2MzRKHRkc/edit) and now it works. It didn’t occur to me

Re: [Kicad-developers] Interpreting the ARC command

On 2019-11-11 7:14 a.m., Wayne Stambaugh wrote: Take a look at the legacy footprint library file format documentation[1] [snip]

Re: [Kicad-developers] Interpreting the ARC command

I've also found https://www.compuphase.com/electronics/LibraryFileFormats.pdf to be useful. On Mon, Nov 11, 2019 at 4:14 AM Wayne Stambaugh wrote: > Take a look at the legacy footprint library file format documentation[1] > for help. You really should be supporting the new s-expression file >

Re: [Kicad-developers] Project save as

ti 12. marrask. 2019 klo 17.43 Jeff Young (j...@rokeby.ie) kirjoitti: > FWIW, the old generated files are not outdated — the paths in them are > updated. > > I was thinking for example gerbers which often (usually?) have project name and revision as graphics in some layer. Whatever the reason of

Re: [Kicad-developers] [PATCH] Eeschema: simulator: more trace colors, smarter color allocation

I have entered the user-configurable colors as a wishlist item into Launchpad so we don't lose it: https://bugs.launchpad.net/kicad/+bug/1852107 . I'd be fine backporting the bug fix, I will leave it to Wayne to decide if the colors should be included or not. -Ian On Mon, Nov 11, 2019 at 7:23

Re: [Kicad-developers] Project save as

FWIW, the old generated files are not outdated — the paths in them are updated. > On 11 Nov 2019, at 23:06, Eeli Kaikkonen wrote: > > > > ti 12. marrask. 2019 klo 0.02 Jon Evans (j...@craftyjon.com > ) kirjoitti: > I question the value of creating this amount of

Re: [Kicad-developers] Tab handling in text rendering and bbox calculation

D’oh. I was thinking our stroke font was mono-spaced, but then why would we have to look up widths in the width-table. I think my brain worked better years ago, but perhaps it’s just nostalgia…. ;) > On 12 Nov 2019, at 12:35, Johannes Sprigode wrote: > > If that is so then I rest my case. >

Re: [Kicad-developers] GitLab migration

Hey Orson, I'm on the fence on this one. I remember similar issues when we migrated from SourceForge. It would be nice if we could migrate just the bug reports that were fixed for 5.1 and later but I'm sure that is not going to be possible because we did not do a great job in the past of

Re: [Kicad-developers] Tab handling in text rendering and bbox calculation

If that is so then I rest my case. Apart from that a change in the anti-aliasing settings as suggested by Jeff didn't have any influence at all. Cheers On 13/11/19 1:26 am, Seth Hillbrand wrote: > On 2019-11-12 03:57, Johannes Sprigode wrote: >> Howdy guys, >> >> hate to burst your bubble. The

Re: [Kicad-developers] Tab handling in text rendering and bbox calculation

On 2019-11-12 03:57, Johannes Sprigode wrote: Howdy guys, hate to burst your bubble. The tab/space issue appears consistent, however the actual character alignment kind of sucks. Lower case a, b etc. are only part of the equation. The big guys still seem to have some sway. Screen shot

Re: [Kicad-developers] Tab handling in text rendering and bbox calculation

The artificial fattening of the middle of the character strokes suggests that Johannes has one of the subpixel anti-aliasing methods turned on. While it doesn’t seem like that would have a cumulative effect of more than a single pixel, maybe it's somehow involved. Johannes, does it change any

Re: [Kicad-developers] Tab handling in text rendering and bbox calculation

Howdy guys, hate to burst your bubble. The tab/space issue appears consistent, however the actual character alignment kind of sucks. Lower case a, b etc. are only part of the equation. The big guys still seem to have some sway. Screen shot attached. Cheers On 12/11/19 5:24 pm, Seth Hillbrand

Re: [Kicad-developers] GitLab migration

ti 12. marrask. 2019 klo 11.04 Andrew Lutsenko (anlutse...@gmail.com) kirjoitti: > I think there is value in having all the history in one place. Add to that > much more efficient search utilities and looking up history a year later > will be a lot easier if all of it is in gitlab and not split.

Re: [Kicad-developers] GitLab migration

I’d definitely keep Fix Committed. For Fix Released someone’s either going to try and find them from a plain-text search (which never worked for shit with Launchpad), or from a commit-message. The commit-message will just have the Launchpad number in it anyway, so they’re going to go to

Re: [Kicad-developers] GitLab migration

I think it makes sense to transfer the reports that are fix committed but not fix released. That way we can have the entire v6 history attached to the new milestone and more easily reference those reports in the future. Any that are fix released we can leave on Launchpad. -Ian On Tue, Nov 12,

Re: [Kicad-developers] GitLab migration

I think there is value in having all the history in one place. Add to that much more efficient search utilities and looking up history a year later will be a lot easier if all of it is in gitlab and not split. Just my 2c. Andrew On Tue, Nov 12, 2019 at 12:23 AM Maciej Suminski wrote: > Hi