← Back to team overview

kicad-developers team mailing list archive

Re: Eeschema GAL arc rendering


Le 20/10/2018 à 16:07, Jeff Young a écrit :
> @JP, I thought I fixed the border/background problem.  (It’s also
> possible I just stopped working on it because I wasn’t getting anywhere.)

Hi Jeff,

It is fixed for a given graphic item but not for overlapping items.

But there is still the issue for overlapping items.
The Legacy canvas draws the background, and then (after all background
items are drawn) the outlines, on top of the background areas.

Therefore, in legacy canvas, outlines are never masked by overlapping

> Do you have a case that exhibits it that I can look in to?
>> On 20 Oct 2018, at 12:21, jp charras <jp.charras@xxxxxxxxxx
>> <mailto:jp.charras@xxxxxxxxxx>> wrote:
>> Le 19/10/2018 à 22:12, Wayne Stambaugh a écrit :
>>> I don't know if anyone is aware but there is an issue with rendering
>>> symbols with arcs in the new Eeschema gal code.  Apparently, the legacy
>>> canvas could be tricked into drawing a minimal line width using a
>>> negative width value.  This cause the the gal canvas to draw a rather
>>> interesting blob (you can check this by opening any nor gate symbol in
>>> the 4xxx library.  The solution proposed by the librarians is to us the
>>> minimal 1mil line width but the rendered results are less than ideal in
>>> the legacy canvas[1].  Anyone have any ideas about how to resolve this?
>>> I would prefer that the gal canvases render symbols the same as the
>>> legacy canvas without have two sets of symbol libraries.
>>> Cheers,
>>> Wayne
>>> [1]:
>>> https://github.com/KiCad/kicad-symbols/pull/1059#issuecomment-431447533
>> This is an issue with polylines.
>> In 5.0 you cannot even select a item having a negative line width.
>> This is an issue with very large negative values ( a value = -1 does not
>> create this issue) for line width.
>> I just committed a workaround for this issue.
>> This is a workaround because you cannot (currently) edit items with a
>> negative line thickness.
>> A full fix is a bit more complex, because items with background fill
>> must be drawn on the background at least the filled area), and all other
>> items on top, after the background fill, in any case (for instance when
>> moving/placing an object in libedit).
>> I know Jeff has already worked on this problem, so because he has a
>> better knowledge of priority drawings, I'll leave it fix this issue (if
>> he agree, of course)
>> -- 
>> Jean-Pierre CHARRAS
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> <https://launchpad.net/%7Ekicad-developers>
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> <https://launchpad.net/%7Ekicad-developers>
>> More help   : https://help.launchpad.net/ListHelp

Jean-Pierre CHARRAS

Follow ups