The plotting dimensions can be an option in the plot dialog. I don't
want to force the plot units one way or the other.
On 2/14/20 6:30 AM, Johannes Pfister wrote:
> What about changing the plotter and page_info classes to metric? Like
> changing GetSizeMils() to GetSizeUM(), m_IUsPerDecimil to
What about changing the plotter and page_info classes to metric? Like
changing GetSizeMils() to GetSizeUM(), m_IUsPerDecimil to m_nmPerIU
and MIN_PAGE_SIZE to MIN_PAGE_SIZE_UM? I say um because it is the
largest IU (PL-editor) and m_nmPerIU could be an integer (AFAIK). That
would make everything
Hi Wayne,
On 13.02.20 20:47, Wayne Stambaugh wrote:
> One thing that can be said
> for sure about 64 bit internal units is that there will be a performance
> hit on 32 bit architectures. The questions are how much and do we care?
I'd expect that to be negligible compared to cache effects,
Compiling the internal units code multiple times is ugly but it could be
replaced by a pure virtual class that implements the internal units
specific scaling. Although a single common internal unit would be cleaner.
While 64 bit 1nm internal units would solve some issues, we have far
bigger
Le 13/02/2020 à 20:08, jp charras a écrit :
> Le 13/02/2020 à 15:46, Wayne Stambaugh a écrit :
>> Hi Johannes,
>>
>> Thank you for your suggestion but the internal units for each format
>> were chosen for a specific reason. There really is no justifiable
>> reason to change them as they have been
Le 13/02/2020 à 15:46, Wayne Stambaugh a écrit :
> Hi Johannes,
>
> Thank you for your suggestion but the internal units for each format
> were chosen for a specific reason. There really is no justifiable
> reason to change them as they have been carefully selected based on the
> requirements of
Hi,
On 13.02.20 16:06, Thomas Pointhuber wrote:
> The solution discussed was to move to 64bit and to use
> constexpr/templates handling unit conversion. So a programmer can for
> example enter 2mm and the compiler automatically converts it into the
> internal unit like nm.
> I'm still in favour
Hi Wayne,
I think, I was present at FOSDEM 2019 when talking about this issue.
From what I understand, the current approach requires KiCad to compile
the units for each package separately (because e.g. mapping IU<->mm is
always different). This has two big problems:
1. the same code has to be
Hi Johannes,
Thank you for your suggestion but the internal units for each format
were chosen for a specific reason. There really is no justifiable
reason to change them as they have been carefully selected based on the
requirements of the objects they represent. Conversion code is provided
for
The KiCAD code uses all kinds of different units for distances.
Amongst other things I found:
nm: pcbnew internal units
10nm: Gerbview internal units
100nm EEschema internal units
1um: PL-Editor internal units
0.1mil (2.54um): SetViewport
1mil (25.4 um): WS_DRAW_ITEM_BASE and
10 matches
Mail list logo
