kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

I've seen the function that check for "ASCII" (quoted, since actually it
checks for the latin-1 set) characters. If the idea is to reject
characters not valid in DXF strings (to decide if plot is the text as
lines) the check is not completely correct, depending on the target
reader. IIRC it was added since russian characters didn't show up
correctly.

The issue is that DXF *does not* specify character encoding until IIRC
AutoCAD 2000 where they added some unicode support and probably you can
actually write a DXF in UTF8 (but then probably only autocad recognizes
them). 

>From the DXF reference the rules seems to be as follows:
- Maximum encoded text length 256 bytes; after that dxfin *can* reject
  the files; I think it's better to *not* enforce this since probably
  newer version and other programs can handle it. Maybe only a warning?

- For controls characters (codepoint under 32) you should use the '^x'
  syntax, and the ^ character should be encoded as '^ ' (that's a space
  after the caret)

- Other characters are interpreted *using the font encoding*. In fact
  even the newline as a SHP descriptor (to advance to the next line).
  The standard fonts are ASCII (codepoint 32-127, plus newline and
  usually TAB), plus 3 special character at codepoints 128-130
  (plus-minus, minus-plus and diameter symbol, IIRC). This is *not* part
  of the DXF specification. In fact the specification doesn't say
  a thing about that.

- The upper bank (128-255) is at the mercy of the font encoding. Most
  SHP fonts are empty here.

- Bigfonts are completely unspecified in the specification. We don't do
  CJK anyway so it's not an issue.

- Newer autocads know about Unicode and can use the \U+xxxx syntax. At
  least for MTEXT primitives (which have also other control codes). Of
  course you would have to use a font which contains them.

In short, at the moment: ^ support is missing (I forgot about that!),
the Latin-1 section is more or less unsupported and extended characters
force a stroke plot.

We could leave it this way until somebody complains. Otherwise I think
that the best way to handle it is to export to the UI the 'plot text as
lines' option (the textmode) and either plot everything or otherwise
export the extended characters with the \U+ notation, so everybody is
(or can be) happy.

I'll put the ^ in the queue, if someone is bored and want to add the
option to the plot dialog I'll do the required export modifications
(which are easy, anyway).

-- 
Lorenzo Marcantonio
Logos Srl