[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

gEDA-bug: [Bug 720218] Re: gschem postscript output lacks some UTF-8 symbols



** Attachment added: "Test file"
   https://bugs.launchpad.net/bugs/720218/+attachment/1854226/+files/fonts.sch

-- 
You received this bug notification because you are a member of gEDA Bug
Team, which is subscribed to gEDA.
https://bugs.launchpad.net/bugs/720218

Title:
  gschem postscript output lacks some UTF-8 symbols

Status in GPL Electronic Design Automation tools:
  New

Bug description:
  To reproduce the problem you can do the following steps:
    - print attached 'fonts.sch' from gschem;
    - change 'Helvetica' to 'NimbusSanL-Regu' manually within it (this font
      substitutes for 'Helvetica' in my Debian 5.0 (Lenny) system);
    - look at the result in any postscript viewer, e.g. 'gs fonts.ps'.

  I've tried different free postscript fonts in my system and the problem was
  the same.

  Font names in gschem are strictly set in o_text.c for displaying and in
  f_print.c for printing, namely 'Helvetica' or 'Arial'.
  If postscript font with that name is missing an operating system substitutes
  some other font for it.

  f_print_stream() function initializes glyph table for printing using
  f_print_initialize_glyph_table() function which contains 'glyph_list'
  structure. 'glyph_list' is an array of glyph descriptions consisting of
  'key'-'name' pairs where 'key' is Unicode value for glyph and 'name' is glyph
  name.

  A prerequisite for the issue is that gschem outputs postscript fonts with
  incorrect specification. Postscript specification of fonts is specified in
  Adobe Glyph List standard (AGL)
  (see http://partners.adobe.com/asn/developer/typeforum/glyphlist.txt,
  http://partners.adobe.com/asn/developer/typeforum/unicodegn.html)
  and it should be using by all programs which output postscript code. Gschem
  font printing has some bugs in comparison with that specification which are
  shown below.

  'ghostscript' program in my Debian system has version 8.62. It translates
  glyph names to Unicode values still according to AGL version 1.2 (what is
  performed by 'gs_agl.ps' code in its distribution). So some glyphs not covered
  by this standard do not appear on a paper when printing. The reason here is
  that f_print.c actually has multiple mappings for some Unicode values and only
  last mapping in f_print.c listing is used for glyph output. Moreover some of
  these values are mapping to names presented in AGLv1.2 (and therefore such
  glyphs are compatible with AGL version 2.0, see below) but the rest has the
  names significant in AGLv2.0 only. 'ghostscript' uses '.notdef' to substitute
  for unknown symbols so we have them all missing in output.

  The issue can be solved by using some of ttf-fonts with proper encoding, such
  as fonts from Liberation family or non-free M$-fonts, but it is a workaround
  only since not all systems have such fonts and not all users would like to
  recompile programs.

  All that said I should add that for the real backward compatibility for
  the postscript output we should use the glyph names in AGLv2.0 which are
  also presented in AGLv1.2, the more so that the AGLv2.0 standard doesn't
  violate AGLv1.2 but only extends it (see below).

  The names of glyphs for printing are interpreted in 'f_print.c'. They mainly
  match AGLv2.0 specification. There are some differences (bugs) though.

  1) After sorting out 'glyph_list' in 'f_print.c' you can see that some keys
  (Unicode values) have multiple mappings. Sorting out is performed in attached
  patch 1.

  2) Unicode key sequences for some languages, such as hebrew and arabic, are
  wrongly mapped. When the AGLv2.0 standard uses key sequence of two or more
  keys for some glyph name, these sequences are broken up wrongly in
  'glyph_list' into multiple key-name pairs with the same name. See patch 2 for
  further details.

  3) There are multiple values for the same names not only for arabic and hebrew
  languages. Other glyphs such as cyrillic and some special have the same issue.
  Moreover the names chosen for output are not always backward compatible with
  AGLv1.2 as it would be. The issue is solved in patch 3.

  
  ** Note about differences between AGLv2.0 and AGLv2.0 standards **

  The differences excluding adding of new symbols in 2.0 are shown in the table
  below.

  | Key  | Name in v1.2   | Name in 2.0               |
  -----------------------------------------------------
  | 0020 | space          | space                     |
  | 00A0 | space          | nbspace, nonbreakingspace |
  | 002D | hyphen         | hyphen                    |
  | 00AD | hyphen         | sfthyphen,softhyphen      |
  | 0162 | Tcommaaccent   | Tcedilla, Tcommaaccent    |
  | 021A | Tcommaaccent   | -                         |
  | 0163 | tcommaaccent   | tcedilla, tcommaaccent    |
  | 021B | tcommaaccent   | -                         |
  | 00AF | macron         | macron                    |
  | 02C9 | macron         | firsttonechinese          |
  | 0394 | Delta          | Deltagreek                |
  | 2206 | Delta          | Delta                     |
  | 03A9 | Omega          | Omegagreek                |
  | 2126 | Omega          | Omega                     |
  | 00B5 | mu             | mu                        |
  | 03BC | mu             | mugreek                   |
  | 2044 | fraction       | fraction                  |
  | 2215 | fraction       | divisionslash             |
  | 00B7 | periodcentered | periodcentered            |
  | 2219 | periodcentered | bulletoperator            |
  | 015E | Scedilla       | Scedilla                  |
  | F6C1 | Scedilla       | -                         |
  | 015F | scedilla       | scedilla                  |
  | F6C2 | scedilla       | -                         |

  You can see that in AGLv2.0 compared to AGLv1.2 only those names are changed
  or deleted which have been presented for other keys.

  In other words AGLv2.0 standard doesn't violate AGLv1.2, but only extends it
  and eliminates twin names.

  So we can support simultaneously the both standards for backward compatibility
  with many old programs and fonts.




_______________________________________________
geda-bug mailing list
geda-bug@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-bug