[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
** Tags added: libgeda printing
** Changed in: geda
Status: New => Confirmed
** Changed in: geda
Importance: Undecided => Medium
--
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:
Confirmed
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