Jump to content

Recommended Posts

As I search the forum, this very severe difficulty/bug makes my migration to APu miserable.

I just have startet to built up a layout for a municipal periodical. I'm in typesetting since over 25 years, using Mac, .indd and my standard fonts (like "Berthold Akzidenz Grotesk"), system admin.

The test-layout consists of 5 pages with text starting at page 2-3 with text frames chained up by hand and one text frame for a picture captation.
There are a lot of tests with other fonts (to get optimized space requirement for the lot of text, later in the final issue) and intense work with styles ...

As I export that test file to PDF/X-3 or -4 the 5th or 6th time, I get the note: The file <path and name.pdf> could not be written" (or created?. I use a German version). What a horror, if that occurs 2 days befor printing!?

- this is the second time, I run into that "no go".
- may be, this occurs if one has a text overflow (in a not-linked text frame)? Even, if you repair that by linking that text frame with a next one on the next page?
- is APu addicted to postscript printer drivers? I have a Xerox printer with original Adobe Postscript (oh, dear ...) and the last days I updated it. Failure despite or because that update?
- may be, there is an inconvenience with fonts, which have an "embedding flag"? In all my decades of (Mac) praxis, I *never* had been confronted with that nonsense. But now with APu?

>> There can be any bug in a new publishing software, but PDF export has to run under any circumstances and whatever barbwire a user has filled into his layout. An PDF export has to go (may be, not a good PDF, but anyway one).

This reminds me of my times with QuarkXpress: After *weeks* of layout on a catalogue for an art auction house, all the sudden in the morning Quark tells: The file couldn't be opened ...! (ahgrrr)

"Any help is appreciated"

Thanks,
Johannes

Share this post


Link to post
Share on other sites

Oh,  thank to You! I'm happy, that a skilled person reads along...

As for the moment, I can't provide you with exact that erroneous file :-(  Today, I spend a lot of hours in restoring (and setting up) the whole startup volume of my mac. After updating the Xerox printerdriver and those APu PDF export errors, I decided to return to the previous version of that driver and did a whole restore. And in the course of that action the test file, which resides on the desktop of the HD, is gone ...

I'll try to replicate that problem (for it's the second time for me) and will return to that topic here. (Although I am really not keen on to getting again in that situation...)

Excuse my question: Has APu already such a function "collect for output..." so that I can provide the fonts used? Until now, I didn't need and therefore didn't seek for such a menue item.

Thanks  a lot!
Johannes

Share this post


Link to post
Share on other sites

Hello DWright,
today I have restored via Mac Time Machine the faulty test layout, which refuses to be exportet as PDF/X-3 oder /X-4 out of APu.

I have send it to the Dropbox link, you gave me.
I would be *very* happy, if that issue could be generally solved. I do not dare to think, that I work on a complex layout hours and hours, and finally APu refuses to generate a PDF for Offset printing ...
If you need further informations - I'm willing to help in any way.

Many thanks!!
Johannes

Additional information: In the meanwhile I replaced a certain part of the text set in the font "Berthold Akzidenz Grotesk Regular", which I would use since decades, by an other font.
The PDF-export is now successfull, with the observation, that APu renders all remaining texts, which are set in other styles of Akzidenz Grotesk, to outlines (this was not selected in the PDF-export setup), exept the text in the substituted font, which is embedded.
This may the difficulties boil down to difficulties of APu dealing with (old? Mac-)fonts. It seems that APu considers those text container with Berthold AG as "non supported effects" and renders them to outlines, except the conatiner with the substute font.

 

Edited by jweitzel
additional technical informations added

Share this post


Link to post
Share on other sites

Hello DWright,
I'M happy in sending the files with great care. I re-extracted the original .zip file, which I sent to dropbox, - and the screenshot shows, that these fonts do go on the journey with all bits and bytes.

The phaenomenon of empty font files come, when those old Type 1-fonts change the file storing plattform/protocoll during transfer (afp/smb, ftp). At the start of desktop publishing, Apple used the postcript font files of "Type 1", splittet in the so called "screen bitmap font" (here in the screenshot: Font Suitcase) and the Postscript font itself (here: Postscript Type 1 Outlinefont). The screen bitmap itself consists of the so called "data fork" (which is empty at screen bitmaps) and the "resouce fork".
Mac OS can handle these complicated file structure till today very confidently. But in companies, where files have to hop between NTFS, HFS and afp, smb, ftp, old fonts get dameged very quickly.
If dropbox exctracts .zip files of its own (I don't use it) and stores it on the "false" volume, you will ever get empty Bitmap Font files.

I hope, the files now arrive safe and sound 🙂
Many thanks for your work and patience!

Johannes

 

Screen-Shot_JWe.jpg

Edited by jweitzel
trimmed the screenshot

Share this post


Link to post
Share on other sites

Hello DWright,
may be, are there any new news about that case? I would be very interested in a response from your side as expert!

Years ago – as I said, to the time of Mac fonts consisting of screen bitmap file and outline PS file – I invested in "my" publishing company about 10.000 Euros in the basic equipment of fonts for typesetting books (Garamond, TimesTen, Helvetica, Palatino, Optima, Futura, Univers and so on). And these fonts are still in use until today (apart from the fact, that only for those old fonts you are today allowed, to generate (book-) PDF files with embedded fonts and *sell* them for money. Today you would have to purchase very costly additional font licences).
Therefor we have +/- all those fonts still in use and e.g. Extensis "FontDoctor" still finds them all as ok.

As I said above, APu should try to generate (more or less) even in those cases (a somehow "impaired" font?) a PDF. May be, not a valid one, may be with error log. But only to say "a pdf could not be generated" and letting the user alone, is quite irksome.

Your help and expertise are welcome!
Johannes

Share this post


Link to post
Share on other sites

Hi There! 

I also have unfortunately the problem to export files into PDF. (german windows version)
The export stops in the middle or the programm is crashing. 

I tried to solve the problem and figured out, if there could be an problem with the export setting, but non of them worked. 
I also tried to install the older 1.7.3 version, but once you opend the file in the new version, the older one won't open it. 

I see i am also not the only one with that problem, hopefully the team is figuring it out soon.
Thanks. 
 

Edited by ABaerm

Share this post


Link to post
Share on other sites

Hello ABaerm (Bärm?),
in my case it boiled down "in the first instance" to an issue with a certain font face, altough that font works fluently in all other environments.

Therefore it would be an idea for you to "deconstruct" (a copy! of) your document element by element and each time to try the export.
May be, the whole file is damaged - may be (as in my case) there is a single frame or element, which causes that issue.

But nevertheless APu is a gorgeous piece of software and the Affinity team has done a real great, admirable job! Really.

Johannes

Share this post


Link to post
Share on other sites

Hello Johannes, 

at first i will thank you to your idea of solivng my problem. 
I tried different thing. Made a new document and insert a variation of my slides into the new document. At first nothing happend... But the export was working in a new simple document. 
So the export got stuck at specific slides. The problem was coming from complex vector graphics i inserted from Designer. The graphics were not rasterized, so the export failed. 
I rasterized all complex sketches/vector graphics and the export also worked with the old file. 

I am not sure if this is really good, cause the new very nice feature of AP is to manage different types of graphics at the same time in all 3 programms. And if there are problems with the vectors and you have to rasterize them, the connection get lost. But this could also be a problem with the hardware. i don't know. it worked in the older version. 

And to your last point. I am defenetly with you. The Affinity Team did and does a great Job, that's also why i put so much trust in to them and bought all programms. 

Greetings 
Alex 

Share this post


Link to post
Share on other sites

Same issue. In my case, I found that was occure when I have a PostScript Type 1 font. If I convert my text to curves, I have no issue anymore. It's OK when I have just one page, but when I have several pages, it's a real problem.

Share this post


Link to post
Share on other sites

I can confirm the problem of embedding any of the PS Type 1 fonts I have tested so far, e.g. Zapf Dingbats, Zapf Chancery, ITC Korinna, all from Adobe Font Folio 8, on macOS Mojave, both with Affinity Publisher version 1.7.3. and latest version 1.8.1., at least when trying with PDF/X-1:2003 export version. The PS1 fonts need to be converted to curves (using an export setting) to have the PDF created, everything else results in an error at export time.

When trying this on Windows versions (both 1.7.3 and latest 1.8.x beta), there are no problems in embedding at least the PS1 fonts I have tested, except for Zapf Dingbats, which strangely fails to render properly (see below an example).

When creating PDFs on macOS with exactly same text and fonts using QuarkXPress 2018 and Pages, there are no problems, and in FontBook all tested PS 1 fonts pass font validation with all green flags (as can be expected as these are original PS fonts from Adobe).

While PS1 fonts are "deprecated" (which means that font manufacturers wish users to repurchase the fonts they already own) -- and their support is dropped e.g. in future versions of certain non-press-oriented apps like Photoshop, as far as I know they are still fully supported even on macOS Catalina (not tested as I do not have it installed), and by print industry. Whether they are also deprecated by Affinity, I do not know (at least fonts get listed on menus so they are not categorically omitted, as they currently are e.g. in Microsoft Office 365), but that would make them stand out from the competition and not in a good way. 

Below: Zapf Chancery, (Zapf Dingbats unrendered but embedded), and four styles of Frutiger, exported as embedded fonts from the latest Windows version of Publisher:

ps1fonts_apub.pdf

EDIT: Note that when I tested this on macOS Mojave I had both 1.7.3. and 1.8.1 versions installed simultaneously, as the OS offered the option to keep both. I do not know if this has any effect on the matter (e.g., if PDF Libraries should be separate), but before (reinstalling) 1.7.3., I produced the error with 1.8.1. installed alone (or as an upgrade) so at least the latest version has this error. Just thought it might be worth a note as I find it odd that macOS users of Affinity apps have not complained about inability of embedding PS1 fonts before (or then I have just completely missed these topics).

EDIT2: I uninstalled 1.8.1 and reinstalled 1.7.3 on macOS Mojave and retested. No change but now I tested non-PDF-X-based exports with font embedding and they all succeed, even when using PDF1.4 (lowest supported in Affinity apps). I cannot figure out why PDF-X based exports conflict with embedding of Type 1 Postscript fonts on macOS, as they do not on Windows. None of the manual export settings seem to trigger similar behavior so it seems to be something "under the hood" involved in PDF-X exports that causes this behavior. 

Share this post


Link to post
Share on other sites

Thanks to both of you for your informations and the efforts to collect them!

At the moment I'm helpless too busy to work further on that important case, and "Mr. DWright" is not answering any more... It would be a catastrophy, if APu would not process T1 fonts within PDF/X-3. And as you said: Do we hope, that T1 are not "deprecated". May it be conncted with the (not existing) embedding flag (bit) in the fonts?

I'm working with Mojave and APu 1.8.1, but days before the update in 1.7.3 there was the same error. I asked myself, what role the Font managing software (me: RightFont) may play in that setup?

Best wishes to you

Johannes

Share this post


Link to post
Share on other sites
2 hours ago, jweitzel said:

It would be a catastrophy, if APu would not process T1 fonts within PDF/X-3. And as you said: Do we hope, that T1 are not "deprecated". May it be conncted with the (not existing) embedding flag (bit) in the fonts?

I have tested now all PDF/X-based export methods using Publisher 1.7.3 on macOS Mojave and they all fail (if you have PS Type 1 fonts in the job). Exporting from QuarkXPress 2018 using the exactly same fonts and text and using PDF/X-based methods (X1, X3 and X4) does not cause any problems. The fonts tested are from Adobe Font Folio 8 and they typically have view & print (read-only) embedding rights (rather than editing), but I do not think this should be a problem, unless Affinity apps embed the font in some none-standard way which does not indicate the correct embedding flag.

If you export using the default (press) setting and then use the PDF version that uses PDF 1.4, and see that your job does not have unflattened transparencies or RGB color spaces, you should be good even without PDF/X routines.

Share this post


Link to post
Share on other sites

Based on further tests it now seems that the problems with exporting jobs containing PostScript Type 1 fonts on macOS versions of Affinity apps (both 1.7.3 and 1.8.1) are indeed related to font's embedding flag.

If there is text that uses a Type 1 font that does not allow embedding or only allows viewing and printing (= read-only), Affinity cannot use PDF/X methods to export a PDF, as it seems that these standards require that fonts with limited embedding rights are correctly marked in the exported file. Fonts that allow editing and/or installing rights for an embedded font do not cause this problem.

It seems that this is simply an omission in macOS versions because a Publisher document using such font, e.g. ITC Korinna from Adobe FontFolio 8 (or practically any other font in this type library, as typically only Adobe's own fonts allow editing for embedded fonts) and failing to be exported on macOS, can be exported with PDF/X methods using the Windows versions of apps without problems.

Before the bug is fixed, the jobs using such fonts need to be exported to PDF either with manually defined "PDF (for press)" settings, or using an export setting that converts fonts to outlines.  

EDIT: I just made one further test that seems to confirm what is said above: using an OpenType font with identical embedding flag from Adobe FontFolio 11 (Univers LT 55 Roman) does not cause export error on macOS when using PDF/X methods so the problem is related to PS Type fonts (with limited embedding rights) only.

Share this post


Link to post
Share on other sites

Hi Lagarto,

that's great, what You have pinpointed! If this turns out to be exactly the cause of these severe problems, there may now "only" the problem to communicate this shortcoming to the developer team at Serif!
In the meantime I got the thought (already mentioned), what role the different font managing softwares may play in that situation: I do not have any clue, how these software hook into the system in order to register fonts (I think a very complex procedure). But apparently with different success (I do know Adobe TypeReunion ;-) , Fontexplorer, Suitcase, now RightFont [latter because it proviedes plugins for old CS 6!]). May be, that there is an other "trap" for Type 1 fonts are "not clean" or not quite registered at the system (and those quirks have to compensated by APu/PDF lib etc.).

Again, thanks to you!
Johannes

 

Share this post


Link to post
Share on other sites
7 minutes ago, jweitzel said:

Again, thanks to you!

You're welcome. FYI, I did not use any font manager on either platform when I ran these tests, and I checked the embedding flags using FontLab 7.

Share this post


Link to post
Share on other sites

This did not get fixed unfortunately in version 1.8.2 but I think that there are multiple problems with Type 1 (some related to symbol glyphs not being correctly mapped to standard characters, some to improperly embedded and prohibiting creation of the PDF, and some to text forced to get rasterized or vectorized because of an effect being applied on it, etc.) so there might be point in trying.

But for the problem I have tested above (PDF/X based export completely failing because the font has limited embedding rights and obviously requires embedding to be made in a specific way)  -- and which may differ from yours -- the new version does not provide a solution.

Share this post


Link to post
Share on other sites

Hello Lagarto,
sorry, that I'm so busy (in home office 😞  ) to go further with my APu project and these font problems... Now, there is APu 1.8.3 out - and these special problems still exist? or solved?

Stay well
Johannes

Share this post


Link to post
Share on other sites
37 minutes ago, jweitzel said:

Now, there is APu 1.8.3 out - and these special problems still exist? or solved?

I do not think that there is any development. I just tested this on macOS Mojave and the same problems exist as before: Zapf Dingbats (from Adobe) fails to export with any PDF method, and ITC Korinna (from Adobe, with embedding restrictions) fails te export when using PDF/X methods. No problems with Century Schoolbook (from URW). QuarkXPress can export all four fonts without problems using any PDF export method. PDF Pages as well, but I do not think that it supports PDF/X methods, so cannot test that.

On WIndows I have not found other problems than ones with symbol fonts: e.g. Zapf DIngbats, which fails on macOS, creates an empty PDF on Windows (everything else in the file exports correctly except this font, which just shows empty space in place of glyphs). Some musical notation fonts have had problems, as well, but I have not re-tested these for a while.

These are all Type 1 specific problems. I do not know if there is any official statement as of intention of continuing support Type 1 fonts (e..g., whether any further development time will be spent fixing problems related to this font technology). I am not sure if they have even logged these anomalies as bugs.

I could test this with some other Type 1 fonts from Adobe Font Folio 8 in the near future just to see how common these problems are on macOS. Catalina might have further problems with old font technology but I cannot test this.

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.