fmt {:g} will sometimes put in scientific notation, e.g. 1.0e6 when we
pass some sizes of numbers. PDF doesn't accept scientific notation for
numbers, so make sure we convert those. Postscript seems to accept these
just fine so limit the fix to PDF.
I don't know that we were hitting these before, but my previous fix for
the background position caused some exponentially formatted numbers.
The PDF plotter's renderWord function now properly handles tab characters
within text. Previously, tabs were passed to HarfBuzz or the stroke font
encoder which would render them as zero-width or small-width glyphs,
causing text alignment issues.
The fix splits text at tab boundaries and calculates proper tab stop
positions using the same algorithm as the font rendering code (TAB_WIDTH
= 4 * 0.6 font units), advancing the cursor to the next tab stop for
each tab character encountered.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/22606
This requires us not resetting PS/PDF's lineStyles
with a "move" instruction.
Also fixes DXF to handle arcs in SHAPE_LINE_CHAINs,
even if it doesn't handle lineStyles.
Creates a Type-3 representation of our stroke font, embeds it in the PDF
and then causes text to be represented in that font.
This prevents the need for over-stroking and keeps our PDFs searchable
and accessible
This still leaves a few things out in the cold,
such as hit-testing and polygon generation.
But at least it allows us to plot with a default
font.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/19031
[Resolve conflicts with JP's fix to same. I'm not sure if we support !m_mirrorIsHorizontal, but
it was in other code, so I left it in just to be
safe....]
Fixes https://gitlab.com/kicad/code/kicad/-/issues/19717
Recommendation is to avoid using the year nomenclature as this
information is already encoded in the git repo. Avoids needing to
repeatly update.
Also updates AUTHORS.txt from current repo with contributor names
The "Plot to PDF" function was producing PDF files that lacked text and
graphic items in viewers like Adobe and Foxit. This issue was caused by
the use of the %g format specifier for floating-point numbers defined in
the PDF specification when writing text and drawing shapes in the PDF.
This incorrect format led to a "Too Few Operands" error during rendering.
To resolve this issue, all floating-point numbers must be specified in
fixed-point format according to the PDF specification wherever the issue
was generated.
Fixes#16465
Jeff Young