Hyphen too long in Postscript output

If "Convert text to path" is not checked if output as
EPS (Encapsulated Postscript), a hyphen is too long.

This doesn't only result in a bad text quality but also
leads to wrong bounding boxes.

A fix would be easy: Just define a new encoding (such
as /ISO1252Encoding which I "borrowed" from
OpenOffice.org) and apply that encoding to the font.

I attached following files:

 test.svg - SVG file with the text
 test.eps - EPS file which shows the problem
 test-fixed.eps - EPS file which includes my proposed
fix, this looks much better (IMHO)

Other attachments

Other attachments

Bernhard:

Your fix works fine, but looks like it assumes that the font
itself is Latin-1. What if it's not?

Also what is ISO 1252? Who defined that encoding and where
is it used?

Don't know, I'm no Postscript expert, but did the previous
code not also assume that the code is Latin1.

1252 is a superset of Latin1 and used in Windows. It
contains characters in positions where Latin1 contains no
characters (e.g. the typographical quotation marks).

Well, if you don't embed fonts it's always a matter of luck
whether that character and that font is available. It
depends on Ghostscript or on the RIP in the printer. I
_guess_ that 99 % of the available fonts support all
character in ISO1252Encoding. The actual encoding of the
font is not important because you define the encoding.
Important are glyph names.

So an easy (but only valid for Postscript Level 2) solution
to support more than Latin1 charset would be not to use
encodings but to directly specify glyphs like this:

/T glyphshow
/e glyphshow
/s glyphshow
/t glyphshow
/hyphen glyphshow
/A glyphshow
/p glyphshow
/p glyphshow
/l glyphshow
/i glyphshow
/k glyphshow
/a glyphshow
/t glyphshow
/i glyphshow
/o glyphshow
/n glyphshow

Well, the postscript becomes bloated but that shouldn't be a
matter in Inkscape because in a drawing application you
don't specify thounsands of letters, I guess, it's not a
word processor :)

The advantage is that you can use more than 255 characters
and have a bit unicode support. The glyph names are
available in
http://partners.adobe.com/public/developer/en/opentype/glyphlist.txt.
Names _not_ available in this list should have the name
/uniXXXX where XXXX is the hex representation of the
character in Unicode. But, of course, it does not work
simply to use /uniXXXX whith other characters (that would be
too easy ;-)).

Of course this doesn't guarantee that the font contains the
glyph. If it doesn't, .notdef must be printed, which is a
space normally. No error message. But if the font contains
the characters on screen it should contain it while printing
if it's the same font and if the font is not buggy (using
wrong glyph names).

I attached a eps file which contains the "Test-Applikation"
string using this glyphshow technique, tested with a
Postscript printer (that's why I use the "Helvetica" font
instead) and Ghostscript.

The question is: How to implement font embedding (Type1,
Type42 for TrueType) properly.

Thanks for the info, it's very helpful. I think we can maybe
use regular text for ASCII (or even 1252?) and the
"glyphshow" for all other chars. Does this make sense?

As for font embedding, actually we even have a patch for this:

https://sourceforge.net/tracker/index.php?func=detail&aid=1219308&group_id=93438&atid=604308

I haven't reviewed the last version of that patch (but I
plan to). It works only for Type1 fonts. If you can review
and/or test the patch it would be very helpful.

Yes, that would be possible (but is a bit more complicated
to implement compared with always using glyphshow, isn't
it?). cp1252 is available in iconv() implementation of at
least Linux (as CP1252 or WINDOWS-1252).

I tested the patch for embedding, it simply crashed in
Inkscape::Extension::Internal::PrintPS::embed_t1() in the
first test (it's a non-standard [i.e. not from Ghostscript
but from a font CD] font, but anyway).

But TrueType (encapsulated as Type42 font) would be
important since on most system most scalable fonts are
TrueType and it would be confusing if only Type1 would work.
If only Type1 is possible at the moment, it would be clearly
mentioned in the UI.

This still doesn't seem to be fixed in 0.46 Win32, although it is a very minor problem.

seems to be fixed by the cairo exporter