Fonts problem with eps files

[superwooman]

hello, we have tried to search for a solution to our problem with eps files but were not able to find any online.

specifically, we created some eps files with a barcode generator software and are able to see the complete image with barcode and numbers below it using Xnview. However, when we opened these files using Designer, the numbers gone missing. Using Adobe Illustrator CC to open these files got a little bit better, the positions where the numbers should be are now seen as little rectangles. In Designer, we do not even have these rectangles.

we do know that eps is not a very good file format in these day and age, but we have clients who still use them. So we have no choice dealing with them.

we also suspect that this could be a font issue, but we have nowhere to look for which font is the cause as we do not even see a "Missing Font" warning.

any ideas?

thanks, William

3857UPC.eps

[h_d]

MacOS 10.15 - AD 1.7.3

Opens fine for me!

 

I don't think it can be a font issue - as far as I can see the characters have been rasterised. 

[v_kyr]

Yes on Macs that UPC-A barcode generated in postcript from bwipp (online generation can be performed here) looks ok ...

... it's generated code looks also fine, though it is ASCII85-encoded (see here) ...

I assume that you maybe are under Windows or? - Since OSX/MacOS can or should usually deal with that easily in any PS/EPS supporting app.

[walt.farrell]

Looking at it on Windows with the Affinity applications, there are no numbers, and there is nothing in the Layers panel that is even a placeholder for any numbers. They're just totally missing from the file.

[v_kyr]

57 minutes ago, walt.farrell said:

Looking at it on Windows with the Affinity applications, there are no numbers, and there is nothing in the Layers panel that is even a placeholder for any numbers. They're just totally missing from the file.

Hmm strange!

Internally as default in it's PS sources that bwipp tool just uses Helvetica or Courier for barcodes. Though on their online tryout page one can define other fonts to use as defined options (options and there text properties). - However the generated EPS output from there (the online generator) encodes numbers as curves. See from ADe on Macs here ...

[superwooman]

Indeed I am using Windows as the OS.

Just as Walt said, the numbers are completely missing when opening the file in Designer.

Opening in Illustrator, we can see placeholders shown in the attached file. Same result from Photoshop.

Opening in an image viewer such as XnView will show the barcode properly with numbers etc. Shown in the attached file.

Interesting to note that all eps files were opening correctly just a few weeks ago with nothing missing.

we had tried eps generated from online barcode generators and from Zint as a locally installed barcode generator.

[superwooman]

I further tested the eps files by opening them with Acrobat DC, and found that they can be opened by Acrobat DC successfully without any missing numbers.

seems like the Postscript "engine" (pardon me if I used the wrong terminology) used by Designer, Illustrator or PhotoShop do not interpret the eps files "correctly" in order to show the proper result. Maybe the generated eps files are not fully compliant to the file standards, or the standards are loosely defined and open to various interpretations. I am not sure.

Currently my observations are that the Postscript interpreters under Acrobat DC and Ghostscript can handle these eps files. While those under Designer, Illustrator and PhotoShop cannot.

[lacerto]

(...)

[lacerto]

(...)

[lacerto]

(...)

[v_kyr]

@Lagarto Related to the OSX/MacOS platform, see in this context ...

Quote

It is widely stated that Quartz "uses PDF internally" (notably by Apple in their 2000 Macworld presentation and Quartz's early developer documentation), often by people making comparisons with the Display PostScript technology used in NeXTSTEP and OPENSTEP (of which macOS is a descendant). Quartz's internal imaging model correlates well with the PDF object graph, making it easy to output PDF to multiple devices.

... and as I've shown here recently for just reusing what OSX Quartz related APIs already offer as PS/EPS support due to it's internal PDF handling & support. Thus for example writing a basic app for PDF handling also takes just a few lines of code, since OSX already offers most functionality ready to reuse. - Thus since Affinity apps on Macs also use the OSX APIs they probably can deal differently here with that stuff.

@superwooman You can try under Windows Zint instead and see how the EPS files from that behave for Affinity, or try Gnu Barcode (which usually generates plain PS/EPS/PCL output) with the PDF output extension instead (see: Gnu Barcode + PDF here). - Another possibility might be a vector file format converter from EPS to PDF/SVG if the EPS format makes trouble in ADe under Windows.

[lacerto]

(...)

[v_kyr]

Well I think Microsoft has always favored its own proprietary vector formats, they supported Postscript themself more neglected. Also only a few MS apps know to deal with PS/EPS in some more or less usable manner. Instead they always have let Postscript/EPS to be handled more by third parties and of course Adobe, even the Postscript format has been well described at all. Thus MS programmer APIs didn't had direct support for it.

Excerpt from PostScript Format Family ...

Quote

... PostScript has been widely used in commercial printing systems since the mid-1980s. Laser printers used with personal computers almost always employed PostScript through the 1990s. The Wikipedia entry for PostScript, indicates, "By 2001, few lower-end printer models came with support for PostScript, largely due to growing competition from much cheaper non-PostScript ink jet printers, and new software-based methods to render PostScript images on the computer, making them suitable for any printer; PDF, a descendant of PostScript, provides one such method, and has largely replaced PostScript as de facto standard for electronic document distribution." In 2017, the Macintosh operating system has built-in support for rendering PostScript files in the Preview application, and for saving print output as a PostScript file. For Windows, Microsoft supplies the Microsoft PostScript Printer Driver but this driver is not shipped with Windows by default.

The use of PostScript as an interchange format for documents has been most common for scientific articles. See the explanation of PostScript Variants available as output from the arXiv repository of physics preprints. In most contexts, direct use of PostScript as an interchange format for documents has been superseded by use of PDF.

A key resource that supported the use and adoption of PostScript is Ghostscript, an interpreter for the PostScript language. According to the Wikipedia entry on Ghostscript, Ghostscript was originally written by L. Peter Deutsch for the GNU Project (an early example of a large-scale collaborative effort for building free software), and released under the GNU General Public License in 1986. Among other functions, Ghostscript can be used as a raster image processor (RIP) for converting PostScript page descriptions for transmission to raster printers without embedded PostScript support. Ghostscript can also be used to convert PostScript documents to PDF. Ghostscript was ported to many operating systems, including Unix-like systems, classic Mac OS, OpenVMS, Plan 9, MS-DOS, FreeDOS, OS/2, Atari TOS, AmigaOS, and Microsoft Windows. ...

Third party software like the Affinity apps do rely here on third party libs for certain file format handlings, in the same manner as does a lot of other software on the market. And the quality and offered functionality/complexity of third party libs do vary a lot, the realy good and platform portable commercial stuff here is always pretty expensive to license. Further there are only very few companies and people which know the whole PS/EPS/PDF format stuff realy as well and deeply good as their mother of invention (namely Adobe here).

[R C-R]

1 hour ago, v_kyr said:

Excerpt from PostScript Format Family ...

Also from that Library of Congress webpage there is this (emphasis added):

Text
Normal rendering	PostScript is designed for preparing page-oriented documents for printing. Scaling, zooming, printing are expected functionalities for PostScript viewers. Indexing the full text content of a PostScript document cannot be guaranteed.

I am not entirely sure what "Indexing the full text content" refers to, but it seems relevant. Can anybody explain what that means in simpler terms?

Also, mostly as an aside (& I realize of no help with the OP's problem) there are two links on that webpage to articles that discuss Adobe's views on PDF vs. Postscript:

In the Postscript verses PDF one, someone from Adobe says Postscript "does not provide for really reliable end-to-end workflows."

The Postscript vs. PDF link is actually to a 2015 Wayback Machine archive & no longer available directly from adobe.com, but although it might be a bit dated, it still provides what is to me one of the clearest & easiest to understand explanations of why PDF is generally a superior file format.

[R C-R]

2 hours ago, Lagarto said:

It is a bit embarassing for a vector graphics app that PostScript is not properly supported on Windows or iOS.

Considering the info in my previous post about text in eps files, I can't agree that there is anything embarrassing about this, but I am surprised that the Mac & iPad versions of the Affinity apps do not treat OP's eps file the same way.

[lacerto]

(...)

 

[superwooman]

@v_kyr thanks and yes, we mentioned Zint was used as a locally installed barcode generator, and its eps output has the same effect as the bwipp eps file.

@R C-R indexing a text file simply means creating an index file that will aid the search efficiency for words within this text file. In order to build an index, raw plain text must be available, but the Postscript file has many extraneous stuff beside the text content (and the text content can be mingled)

@Lagarto thanks, I believe it can be a font issue as well. More specifically, we suspect a font issue with our system (not the eps file) that causes the problem with Illustrator, which we will have to resolve.
Finding out that Designer does not play well with eps on Windows systems is a surprised discovery.
We agree that this is a serious issue, because it would be disastrous to have a piece of artwork going into production without realizing that some element is missing. Affinity software is changing rapidly, and we are sure many things will be fixed. Until then, I can only use it as a secondary piece of tool. We lost tens of thousand dollars many years ago using FreeHand for more or less the same reason, i.e. not realizing we are missing some elements.

@Lagarto@v_kyr thanks folks for your work around suggestions.
At the meantime, we can save the barcode generated in svg format, and resave it as eps or ai with either Designer or Illustrator. The resulting eps will open without any issues by either applications.
If we have no control on the file format of these eps artwork submitted by clients, we can open these "problematic" eps files with Acrobat DC and save it as PDF. Open the PDF with Designer or Illustrator, and then resave in whatever eps or ai format. Again, the resulting eps files will open without any issues by either.

In summary, we met a problem with opening certain eps files using Illustrator, and thought that Designer would come in to rescue. But found out later with all your help that Designer has a platform issue with these files. We would have to leave it at that with Designer as it is not my place to dictate Affinity's path.
As an end user, we tend to agree with Lagarto that an app suited for professional market should be more robust, but we also understand v_kyr saying that it could be a business decision made by Affinity for the current moment. Things might change down the road. The mere fact that we are all here means that Affinity is already doing a pretty decent job. A++ for the Affinity team.
We have workaround as stated above, but would prefer to have a permanent solution, which we will have to take it up to an Adobe site since this is boiling down to an Illustrator related issue. (Though they might just say it is my own problem since it could be system specific)
I am just surprised that, since all Adobe app on our system use the same common files for Postscript interpreter and font set, the result from Acrobat is different from Illustrator or PhotoShop.
Many times in business, we have to deal with files submitted by clients rather than created by ourselves. We have to incorporate these client submitted files into our final output. Which means the choice of file format is not in our hands, and we need a reliable and trustworthy way of handling them.

Thanks all. If later we found a solution for our Illustrator problem, I would like to post it here so we have proper closure.

 

[superwooman]

ok, I did not expect finding out the problem so quickly, but thanks to all you folks doing the testing, and @Lagarto hinting to the right direction, the problem is solved by removing a corrupted Helvetica font mapping (I think).

after deleting the Helvetica font file from our system (we only have Helvetica Regular, no Helvetica Medium BTW), the file opened correctly in Illustrator (with numbers and all) even though it throws a missing font warning.

Designer still opens it with no numbers showing. Probably due to reasons Lagarto described.

[lacerto]

(...)

[v_kyr]

@superwooman Another thing to keep in mind here for Postscript based tools like bwipp, beside of course of having correct behaving fonts for needed font families installed, is to use for such Postcript related apps (like bwipp) also the right fonts Postscript naming here. This is for example especially important when assigning another font to use then with the bwipp option settings. - Just the Courier and Helvetica Postscript names here:

• Courier-Bold
• Courier-BoldOblique
• Courier
• Courier-Oblique
• Helvetica-Bold
• Helvetica-BoldOblique
• Helvetica-NarrowBold
• Helvetica-NarrowBoldOblique
• Helvetica
• Helvetica-Oblique
• Helvetica-Narrow
• Helvetica-NarrowOblique
• etc.

(See also the Adobe Font Name reference table here).

So you could also use or test with some other of your systems font family here, as far as you know and use the fonts PS naming.

Note further that actually in its current state/form the Affinity apps EPS and SVG parsers are by no means able to make full use of the respective EPS/SVG formats specs. So there are certain things they can't deal at all with for these file formats and thus they are restricted in some more or less ways here. - Related to Illustrator, I would expect that it can deal with every of Adobe's own file formats much better than any competitor here or any other third party software. The same applies to Acrobat here.

I can imagine that the conversion route you have to take for client submitted EPS files actually, is suboptimal here for when using the Affinity apps. Some foolprove converter would be good to have here, ideally one which simplifies the related output format in a way the Affinity apps can deal with it.

[superwooman]

thanks for the additional takeaway. It will come in very handy for future work.

bottomline - no tools are perfect. We just have to be familiar with the tools' strength and limitation, and make good use of them.

much appreciated.