Jump to content

Recommended Posts

Posted

I have been having an issue with font weights (such as semibold, bold, etc) when exporting as PDF.

When using default 'rasterise: unsupported properties', everything renders correctly in the application and preview pane, but the exported PDF just uses normal weight for everything.

When using 'rasterise: everything', the output is correct but filesize is bloated.

In my example, I used normal, semibold, and bold in the sample paragraph. But it doesn't seem to make any difference which of the variants is used.

---

Affinity Publisher 2.0.4

macOS Ventura 13.3.1 (22E261)

Intel MBP 16" 2019; AMD Radeon Pro 5500M 4 GB; 32GB RAM

Posted

Hi @MarcBPL and welcome to the forums,

You need to ensure you have the static versions of Open Sans installed rather than the variable font version as variable fonts are not currently supported.

I just uninstalled the variable version of Open Sans and replaced it with the static version and everything then exports correctly using the correct font weights.

Affinity Designer 2.6.0 | Affinity Photo 2.6.0 | Affinity Publisher 2.6.0
MacBook Pro M3 Max, 36 GB Unified Memory, macOS Sonoma 14.6.1, Magic Mouse
HP ENVY x360, 8 GB RAM, AMD Ryzen 5 2500U, Windows 10 Home, Logitech Mouse

Posted

Thanks, that's disappointing given the widespread use of variable fonts.

It seems like it's mostly supported as it works well in the UI, print, export preview window, and rasterised PDF. I guess it must be a PDF-specific limitation? 

I can see from your signature that you've tried the latest beta; do you know whether the issue been addressed or whether any insight has been given on whether Serif will address it soon/at all? 

Posted

I believe Affinity software uses the PDFlib 9.3.1 library... This is what the PDFlib 9.3.1 spec says regarding Variable fonts which is the same as the PDFlib 10.0 spec...

Quote

OpenType font variations, also called variable fonts: fonts that use OpenType font variations mechanisms can be used to package multiple font faces within a font family (such as light, regular and bold) into a single font resource. Since font variations are not supported in PDF this mechanism cannot be used. OpenType font variations with TrueType outlines can be loaded with PDFlib, but only the default font instance without variations will be visible. OpenType font variations with PostScript outlines in a CFF2 table are rejected since they are incompatible with PDF.

They are not supported in the current Beta and as far as I'm aware there have been no announcements from Serif regarding future support though it is obviously something that has been requested numerous times in the forums, however you also need to be aware, as you've rightly surmised, that the PDF specification itself doesn't support variable fonts... this is from Dov Isaacs a former Adobe Principal Scientist a couple of years ago and as far as I'm aware this is still the current situation unless anything has changed in the intervening years...

Quote

As much as Variable Fonts do represent new and exciting technology with much potential going forward, you may wish to limit your use of these fonts at this point especially for production workflows! Why?

Be aware that Variable Fonts are not directly supported by PDF. This isn't a matter of what can be supported by Acrobat or other PDF viewers, but rather it is an issue of Variable Fonts not being supported at all by the PDF language specification, including PDF 2.0 and the upcoming PDF/X-6 and PDF/A-4 specifications. It may be several years before such support is added to the PDF specification and according support added to PDF viewers (such as Adobe Reader and Acrobat). If you do use Variable Fonts in an InDesign or Illustrator document, generated PDF (as well as PostScript and EPS) use derived “instances” of the Variable Font  based on the settings for the text being formatted. As a tangible result, text formatted in these applications using Variable Fonts is effectively not editable within Acrobat! (You can change the text to another, non-Variable Font, but you cannot at all access Variable Fonts within Acrobat!)

Affinity Designer 2.6.0 | Affinity Photo 2.6.0 | Affinity Publisher 2.6.0
MacBook Pro M3 Max, 36 GB Unified Memory, macOS Sonoma 14.6.1, Magic Mouse
HP ENVY x360, 8 GB RAM, AMD Ryzen 5 2500U, Windows 10 Home, Logitech Mouse

Posted (edited)

Thanks.

My understanding of what Dov is saying is that InDesign et al basically derive a fixed subset of fonts from the variable font which are then "concrete/fixed" in a sense. So, the output of the PDF becomes effectively read-only, which would be fine for use-cases like mine. That would require some kind of mapping and transformation process on the Serif side, but I'm a distributed systems guy so I don't really want to overstep the boundaries of my knowledge by speculating how difficult it would be.

Having some kind of warning in the UI would be a nice interim step, as I wasn't aware of the source of the problem so searching didn't give me much (given the array of other similar-but-not-same bugs filed).

Anyway, fingers crossed, they will address this soon as it seems like a common point of frustration. 

Edited by MarcBPL
Typo
Posted

Exactly that, basically what InDesign and other software has to do is to convert the variable font to a legacy format or generate a static instance of each variable and bearing in mind that the Affinity suite uses the PDFlib 9.3.1 library to generate pdf files and variable fonts are not currently supported in the PDFlib library, I don't think we'll see support any time soon...

To be any use in a traditional print workflow I think first we would first need to see full support in the PDF spec, which as far as I know isn't there even in PDF 2.0 or PDF/X-6 (though things may have progressed, but I really don't know) followed by support in PDFlib library for Serfif to be able to support variable fonts in any meaningful way.

Affinity Designer 2.6.0 | Affinity Photo 2.6.0 | Affinity Publisher 2.6.0
MacBook Pro M3 Max, 36 GB Unified Memory, macOS Sonoma 14.6.1, Magic Mouse
HP ENVY x360, 8 GB RAM, AMD Ryzen 5 2500U, Windows 10 Home, Logitech Mouse

Posted
21 minutes ago, MarcBPL said:

which would be fine for use-cases like mine.

If that's fine for your use-case, and if the text looks good in Publisher, then perhaps you could just use the Export setting "Embed Fonts: Text to Curves" to convert the fonts to curves.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
    Laptop 2: Windows 11 Pro 24H2,  16GB memory, Snapdragon(R) X Elite - X1E80100 - Qualcomm(R) Oryon(TM) 12 Core CPU 4.01 GHz, Qualcomm(R) Adreno(TM) X1-85 GPU
iPad:  iPad Pro M1, 12.9": iPadOS 18.3.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sequoia 15.0.1

Posted (edited)
11 minutes ago, walt.farrell said:

If that's fine for your use-case, and if the text looks good in Publisher, then perhaps you could just use the Export setting "Embed Fonts: Text to Curves" to convert the fonts to curves.

Thanks, Walt. I'll give that a crack and report back how it goes.

 

My only concern is that it will mess with accessibility (screenreaders, etc). I know OCR is usually good enough, but I don't like to add barriers unless I need to.

Edited by MarcBPL
Posted (edited)

So, font as curves does indeed work, but the ability for the PDF reader to select text is mixed.

Interestingly, the file size is actually larger in my production sample than using rasterised, likely due to the verbosity of the vectorised output (2.6MB vs 2.9MB).

When I zoom out on Adobe Acrobat Reader the version with fonts as curves looks strange and almost pixellated, whereas the same file looks great on Preview.app. Must be an artefact of the way Adobe's vectorisation rendering has been implemented on macOS.

I suppose these are all just compromises until the real support becomes available.

Thanks again; it's useful to have some alternative workarounds. I'll see what I can do to move over to static fonts.

re: library not supporting variable fonts, a possible workaround would be for Serif to generate their own static fonts, and swap out the problematic ones for the static proxies before passing to the PDF library. But again, that's off the top of my head, and I don't know the complexity of the situation. 

Thanks, everyone. Have a good weekend.

Edited by MarcBPL
Posted
1 hour ago, walt.farrell said:

If that's fine for your use-case, and if the text looks good in Publisher, then perhaps you could just use the Export setting "Embed Fonts: Text to Curves" to convert the fonts to curves.

I see no real advantage doing that, as in, you have no control over any interim optical size, width or parametric axis values for the variable font directly within Affinity software, unlike InDesign, as in, there are no sliders to control these font variations so fundamentally all you are actually able to use are the static equivalents of the variable font, i.e., light, regular, semi, bold, heavy, extra bold and so on, so you may as well just use the static versions in the first place.

Affinity Designer 2.6.0 | Affinity Photo 2.6.0 | Affinity Publisher 2.6.0
MacBook Pro M3 Max, 36 GB Unified Memory, macOS Sonoma 14.6.1, Magic Mouse
HP ENVY x360, 8 GB RAM, AMD Ryzen 5 2500U, Windows 10 Home, Logitech Mouse

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

Terms of Use | 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.