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 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 metric, avoid rounding errors for pages and pen > sizes that are on a grid of 1 um or 10 mil, and it would avoid > calculating the conversations factor to convert from metric to > non-metric, only to then convert the conversations factor back to > convert metric to metric, like it is done when starting a gerber plot. > It would not limit maximum page sizes to a lower limit. > Would you accept and welcome this or do you think this is a bad or useless > idea? > > Johannes > > Am Do., 13. Feb. 2020 um 14:46 Uhr schrieb Wayne Stambaugh > <stambau...@gmail.com>: >> >> 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 each internal unit so plotting to standard units such as >> millimeters, inches, etc is trivial. I'm not opposed to adding support >> for changing the plot units. I am opposed to changing the internal units. >> >> Cheers, >> >> Wayne >> >> On 2/13/20 9:32 AM, Johannes Pfister wrote: >>> 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 GetSizeMils >>> And the native File formats use mm (pcbnew) and mil (EEschema). >>> Something like SVG exports in 0.1 mil steps. I think that this is not >>> very consistent and something like a PLOTTER class needs to handle >>> different IU-sizes. >>> >>> My idea is to rewrite the internal units so that nm are used >>> everywhere inside the source code, and only parts that write or read >>> files and display data to or read data from the user should convert it >>> to another unit system. I don't want to change any file formats. >>> That would make it a bit more straightforward, more consistent, metric >>> and an SVG-Plotter would use a metric step size. The disadvantage >>> would be that there would be an about 2m or 4m limit in every >>> direction, assuming int is 32 bit, which is AFAIK true for all >>> platforms KiCAD current supports. >>> >>> Before i rewrite code, can you say what you guys think about it? >>> >>> >>> Johannes Pfister >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
