I understand that ghostscript can convert texts fonts to outlines with the option -dNoOutputFonts. You may run that before importing into Mathematica.

I spent many years writing PostScrpt drivers and controllers on larger printers, but very little with EPS. One of the concepts of EPS is that it must be self-contained, which is where this is failing.

As an example in where PostScript can have issues due to not being self-contained, and for which EPS was designed to get around this, would be the case of printing out of order. If regular PostScript has definitions of fonts, their glyphs, or character encodings change, then printing out of order will possibly miss the change in one of those and end up using the previous (incorrect) encoding, glyph, font, so on (the change in state relative to font handling is inherited as printing increments from one page to the next...each individual page does not necessarily contain the full information).

A second example is that PostScript can be "optimized for size". In that case definitions of fonts and their glyphs are introduced only at the start of each page which uses them. A regular document would normally introduce the entire character set and not pieces of a character set. Printing this out of order would result in missing graphics for characters not yet introduced.

EPS is designed to be more or less copy and paste (it is an encapsulated block of PostScript, with a few rules about what it must or must not contain), but it has a weakness in that people often assume that although the structure is syntactically correct, that the data is also complete. This results in valid EPS which cannot be printed correctly. In this case you have to either add the missing information into the EPS, or else substitute. This latter is why ghostscript works, but it warns about the missing character set. Ghostscript displays because ghostscript did a substitution. Mathematica fails because it is importing an image which it refuses to do substitution on.

What Mathematica exported is syntactically correct. What Mathematica exported is where the real fault exists. Mathematica could substitute as a "workaround", but it would have been better if it had embedded the information in the first place. If Mathematica has no concept of substitution, then this is a weak point in Mathematica's import mechanism.

Normally an operating system has an environment, and if done correctly, that environment lists the current encoding. This is where the EPS information should come from if it isn't explicitly set by the user in a preference. Either the mechanism to do so broke, or else the mechanism was never run.

EPS can only store 1 postscript page ("encapsulated") - it's a special-use thing that intently does not have multi-page postscript code in it. that being so it may also not include all font definitions or things Import "needs".

if you check Help you can find a full writeup on each Export type of which EPS is one, but perhaps google EPS and you'll find many adobe or unix documents on EPS

I see what you mean now. a Plot exported as EPS then imported the text is missing

Again as other's indicated. EPS was exported without all page description (perhaps viewable in ghostscript perhaps not). The Mathematica Import function using EPS did not understand the whole EPS and dropped the text.

Use PS or PDF, not EPS is the answer there. Your might be able to carefully make the plot text to insure it uses your system fonts that both you and poscript have installed (that Import doesn't have to do any work to import fonts) and it would work. But in general (across different systems), as things are, it is never going to work using EPS.

also - Mathematica's Import functions are FAR FROM PERFECT, some hardly work at all some are very good. do no expect if that ghostscript can "see an eps" that Import[] should do the same equally well. find the Help section and the full writeup page for EPS importer - there's one online to find.

Wolfram probably needs to examine if the character set information is being properly exported to eps. In the case of import, then Wolfram might want to add a fallback when character set is missing.

I see this in a ghostview debug:

Warning: Missing charsets in String to FontSet conversion

Basically the eps isn't entirely valid because it has some definitions, but it doesn't know which character set table to look it up in. It might be UTF-8, UTF-16, ASCII...who knows?

My thought is that there are two possibilities:

• No environment detected character set, and thus inherited environment couldn't pass this on.
• The Mathematic app doesn't take this into consideration (but should).

Btw, if I use my default character set it does display correctly in other applications after a warning.

Yes sure, I only thougt that Export["image.eps",Graphics[Text["A", {0, 0}]]] produces the same file for everybody. But perhaps I might be wrong.

Attachments:

image.eps

The EPS is generated with mathematica with Export[], see the code above. Does the code above work for you?

As written above there is no error-message, mathematica keeps running and cannot be aborted anymore.

I use Windows 10 and Mathematica 12.