Global label size changes with overline

[Chris Pavlina]

I'm not sure when this was changed, but the box around global labels now grows with an overline.

I can sort of understand the logic behind this, but it looks _bad_ when labels are next to each other:

https://misc.c4757p.com/ugly-labels.png <-- latest master

https://misc.c4757p.com/better-labels.png <-- 4.0.5

Application: kicad
Version: (2017-03-06 revision f8415633b)-master, debug build
Libraries: wxWidgets 3.0.2
           libcurl/7.53.1 OpenSSL/1.0.2k zlib/1.2.11 libpsl/0.17.0 (+libicu/58.2) libssh2/1.8.0
Platform: Linux 4.9.11-1-ARCH x86_64, 64 bit, Little endian, wxGTK
- Build Info -
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.63.0
Curl: 7.53.1
KiCad - Compiler: GCC 6.3.1 with C++ ABI 1010
        Settings: USE_WX_GRAPHICS_CONTEXT=OFF
                  USE_WX_OVERLAY=OFF
                  KICAD_SCRIPTING=OFF
                  KICAD_SCRIPTING_MODULES=OFF
                  KICAD_SCRIPTING_WXPYTHON=OFF
                  KICAD_SCRIPTING_ACTION_MENU=OFF
                  BUILD_GITHUB_PLUGIN=ON
                  KICAD_USE_OCE=ON

[Nick Østergaard (nickoe)]

Without testing, but it looks to be from:

commit 30d72045e72689d43c334ed08f83684dcab262a0
Author: jean-pierre charras <jp.charras>
Date: Wed Mar 23 08:41:47 2016 +0100

    Rework on class EDA_TEXT and related classes and draw functions (Note: this is a work in progress):
    * remove duplicate code between draw functions and STROKE_FONT used in GAL. Use only STROKE_FONT methods in draw, plot and test DRC function for texts. I
t remove slightly different shapes between GAL and other calculations.
    * fix incorrect bounding box for texts with overbar. Especially noticeable for texts with overbar inside a copper zone in Pcbnew.
    * fix a few minor other bugs related to graphic texts.

[Chris Pavlina (pavlina-chris)]

30d72045e72689d43c334ed08f83684dcab262a0 (thanks nickoe)?

[Nick Østergaard (nickoe)]

But this change sounds like something that should really be bumping the board version... if using text on copper it will change copper when refilling. See attached.

[Chris Pavlina (pavlina-chris)]

We need to ensure that any fix for this does NOT change the board output in any way, not just bump the board version. If we absolutely cannot or will not fix the bug and maintain identical PCB output for texts on the board then the bug should be marked Won't Fix.

[Wayne Stambaugh (stambaughw)]

Am I missing something. What does the rendering of a global label in eeschema have to do with the board file version? Was there a new board keyword added or were changes made to the board file formatter or parser?

[Chris Pavlina (pavlina-chris)]

Yeah, if I'm interpreting the commit mentioned above correctly, it affects bounding box computation for EDA_TEXT everywhere (including on PCB). Bounding box affects zone fill around text. This could result in sections of zones not being filled that were previously, etc.

[Wayne Stambaugh (stambaughw)]

That's different than a file format change. If the bounding box was
calculated incorrectly (or differently) between canvases, that should be
fixed. I'm not sure what the proper answer is as far as the changes to
fills would be. This is an unfortunate side effect of have two
different canvases.

On 3/6/2017 6:53 PM, Chris Pavlina wrote:
> Yeah, if I'm interpreting the commit mentioned above correctly, it
> affects bounding box computation for EDA_TEXT everywhere (including on
> PCB). Bounding box affects zone fill around text. This could result in
> sections of zones not being filled that were previously, etc.
>

[Chris Pavlina (pavlina-chris)]

That is definitely a file format change, because it results in certain data in the file giving different board output. Absolutely 100% a file format change.

[Wayne Stambaugh (stambaughw)]

I disagree. The file contents have changed, not the file format. No
new keyword tokens or changes were made to the file format itself. We
have never bumped the file format for an object generation bug. We have
fixed lots of zone filling and text rendering bugs that changed the
users boards so I don't see how this is any different.

On 3/6/2017 7:13 PM, Chris Pavlina wrote:
> That is definitely a file format change, because it results in certain
> data in the file giving different board output. Absolutely 100% a file
> format change.
>

[Nick Østergaard (nickoe)]

The file contents have not changed. It is the same kicad_pcb file that renders differently in two versions of pcbnew. Copper is changed when refilling the attached example in current master.

Ideally the text label itself should have a versioning scheme such that a never kicad would know that if it was made with the old kicad it should render in another way. Such versioning detail is of course a bit complex and we do not support this, but it would be really nice to have provisions to handle this nicely. Although I am not sure of the design of such a concept. But for now we do not support that, hence the boardversion really needed to be bumped when that change was comitted ideally.

[jean-pierre charras (jp-charras)]

The so called issue is a bug fix, and only a bug fix:
Before the fix:
* The texts were slightly *different* depending on the canvas in use.
* The bounding box was incorrectly calculated, creating a clearance issue.
It means the DRC could also miss a clearance issue.

This is not the first (and not the last) time a bug fix sligthly change a clearance (or something else).
We never modified a board version when a fix which do not change anything in files is made.
What is the interest: the fixed issue is not in the board file, it is in the Pcbnew code.

[Chris Pavlina (pavlina-chris)]

> The file contents have not changed. It is the same kicad_pcb file that
> renders differently in two versions of pcbnew. Copper is changed when
> refilling the attached example in current master.

No, that's *wrong*. The file contents *required to produce the same PCB* have changed, thus the file contents have changed.

If there is a sequence of letters that is a valid word in two different languages, but that means something totally different in each, would you argue it is the same word?

[jean-pierre charras (jp-charras)]

I disagree.

[Wayne Stambaugh (stambaughw)]

On 3/7/2017 2:09 AM, Nick Østergaard wrote:
> The file contents have not changed. It is the same kicad_pcb file that
> renders differently in two versions of pcbnew. Copper is changed when
> refilling the attached example in current master.
>
> Ideally the text label itself should have a versioning scheme such that
> a never kicad would know that if it was made with the old kicad it
> should render in another way. Such versioning detail is of course a bit
> complex and we do not support this, but it would be really nice to have
> provisions to handle this nicely. Although I am not sure of the design
> of such a concept. But for now we do not support that, hence the
> boardversion really needed to be bumped when that change was comitted
> ideally.
>

This would be a policy change over what we've been doing. I'm not sure
the amount of work and the mess it would make in the code base to
support this is worth the effort.

[Chris Pavlina (pavlina-chris)]

This project's inattention to output fidelity is going to end up being a serious impediment to commercial adoption as we continue to pick up more users. An identical input file should produce identical output files in as many cases as possible, and if that means every version of the format _or change in how it's interpreted_ is considered a totally new format with an importer meant to handle its quirks and everything, so be it. It's unfortunate and burdensome, but that's life.

But I've failed at almost every attempt to convince the leadership of this, so whatever. Think about reconsidering it the next time you're wondering why more engineers don't consider KiCad a serious EDA package for doing real, commercial work.

[Wayne Stambaugh (stambaughw)]

I am not unsympathetic to your argument. I do think it's a bit
alarmist. I don't believe that minor fixes that require the board to be
refilled to fix a clearance bug is keeping commercial users from using
KiCad. Given that the changes were made to the development branch,
there should be even less expectation that these kinds of changes are
not going to happen.

I'm open to this idea in the future when we have a stable unified
geometry library, the manpower to maintain it, and a bug report from a
commercial user who was bit by this and considers it unacceptable and is
willing to pay for this kind of support.

On 3/7/2017 8:13 AM, Chris Pavlina wrote:
> This project's inattention to output fidelity is going to end up being a
> serious impediment to commercial adoption as we continue to pick up more
> users. An identical input file should produce identical output files in
> as many cases as possible, and if that means every version of the format
> _or change in how it's interpreted_ is considered a totally new format
> with an importer meant to handle its quirks and everything, so be it.
> It's unfortunate and burdensome, but that's life.
>
> But I've failed at almost every attempt to convince the leadership of
> this, so whatever. Think about reconsidering it the next time you're
> wondering why more engineers don't consider KiCad a serious EDA package
> for doing real, commercial work.
>

[Chris Pavlina (pavlina-chris)]

Not alarmist, just impatient. It's not so much this particular instance
I have a problem with as the entire mentality. We should have a much
stronger policy of never changing the input->output relationship unless
absolutely necessary.

As for bug reports from commercial users - be careful here - when money
is involved, people make cautious decisions. There are probably numerous
commercial users who have *evaluated* KiCad for their purposes,
encountered an issue or found reports from other people complaining
about it, and simply gave up on it and declared it unfit. When money is
on the line, decisions are made carefully, and nobody is going to waste
paid engineer time filing bug reports for a product they chose not to
use.

[Wayne Stambaugh (stambaughw)]

On 3/7/2017 9:35 AM, Chris Pavlina wrote:
> Not alarmist, just impatient. It's not so much this particular instance
> I have a problem with as the entire mentality. We should have a much
> stronger policy of never changing the input->output relationship unless
> absolutely necessary.

Have you done any testing with commercial products to verify that they
always insure integrity between versions? It would be interesting to
know if this is the case rather than assumptions. If it isn't, then
commercial users obviously don't care about this. Otherwise, they
wouldn't buy them or would they?

>
> As for bug reports from commercial users - be careful here - when money
> is involved, people make cautious decisions. There are probably numerous
> commercial users who have *evaluated* KiCad for their purposes,
> encountered an issue or found reports from other people complaining
> about it, and simply gave up on it and declared it unfit. When money is
> on the line, decisions are made carefully, and nobody is going to waste
> paid engineer time filing bug reports for a product they chose not to
> use.
>

People still shell out money for MS products in spite of all of issues
they have had over the decades. Even the CERN board guys complain about
issues with A****m. If I made my purchasing decisions base on
complaints, I wouldn't be able to buy anything. I think the main issue
holding back KiCad is support. Commercial vendors want to be able to
pick up the phone or send an email for help on demand.

[Chris Pavlina (pavlina-chris)]

> I think the main issue
> holding back KiCad is support. Commercial vendors want to be able to
> pick up the phone or send an email for help on demand.

I think our inability to provide support when SHTF puts a higher burden
on us to ensure S _doesn't_ HTF, to be frank.

[Jeff Young (jeyjey)]

Since nothing more here was reported, I guess we shipped this in 5.0 (and 5.1). Therefore, doing anything at this point will just result in a different set of boards getting changes (ie: those written with 5.0 and 5.1 instead of those written with 4.0).

I'll mark this as Won't Fix. Please re-open if anyone has more to add.