Jump to content
You must now use your email address to sign in [click for more info] ×

Recommended Posts

I’m not so sure. Take the Mac versions as an example. I could be mistaken, but far as I understand, the Affinity apps do not use Core Text on macOS, but are based on a custom text layout and rendering engine that reads the raw font data directly. So handling variable fonts would have to be done by that custom engine. If the Affinity apps were to use Core Text, they could also provide variable font support. As far as I remember, the Mac operating system started to include variable font support in version 10.5. Though “support” certainly meant something different then, compared to what is possible today.

In general, I would also support the request made in this thread. While I used to be sceptical about variable fonts in the past, my mind has changed since. These fonts are highly useful design tools.

Link to comment
Share on other sites

26 minutes ago, A_B_C said:

the Affinity apps do not use Core Text on macOS, but are based on a custom text layout and rendering engine that reads the raw font data directly

They may very well do so, but many apps do not.  While some apps will always break with convention and do things their own way (typically with limitations of various kinds as a result), it makes no sense for the general implementation of features like this to be duplicated across multiple applications when it can be readily provided for by the underlying platform.

Link to comment
Share on other sites

2 hours ago, A_B_C said:

If the Affinity apps were to use Core Text, they could also provide variable font support.

It's not quite that simple, though.

  1. They need something that works on Mac and iPad and Windows.
  2. Even if they had a layout engine that handles Variable fonts, the PDF format does not support Variable fonts. Essentially, any app creating a PDF needs to create a static version of the subset of characters used in the PDF, and embed that newly created static font subset into the PDF.

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

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

3 hours ago, walt.farrell said:

It's not quite that simple, though.

  1. They need something that works on Mac and iPad and Windows.
  2. Even if they had a layout engine that handles Variable fonts, the PDF format does not support Variable fonts. Essentially, any app creating a PDF needs to create a static version of the subset of characters used in the PDF, and embed that newly created static font subset into the PDF.

They already use the FreeType2 library to render fonts in their packages and it works across all these platforms.

It has supported variable fonts (aka variations) since 2017.

Link to comment
Share on other sites

13 minutes ago, DamienG said:

They already use the FreeType2 library to render fonts in their packages and it works across all these platforms.

Interesting. I've never seen that mentioned for the Affinity applications. 

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

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

On 12/18/2022 at 11:05 AM, Old Bruce said:

Does the font foundry have static versions available?

Some foundries are now releasing only a variable font.
Which makes a lot of sense.
The current advanced font development process now uses a multiple master approach, so the sources created are inherently variable.
When the masters sources are done, push-a-button to export the variable font.
Producing the static fonts involves additional steps, and compromises.

Depending on the axes, the number of static fonts can quickly get unwieldy.
Most people just think about weight and width.
Using the OpenType "standard" ten weights from 100 to 1000, and the nine widths from ultra-condensed to ultra-expanded, and italics you get - 10 weights x 9 widths x 2 (regular+italic) = 180 fonts.

Then lets add an optical size axis.
What increment do you use for the optical size static fonts?
Merriweather has an optical size axis of 6pt to 144pt.
They only export statics at 6pt, 12pt, 60pt, and 144pt.
Even with their limited weights and widths, that ends up being 120 static fonts.

Playfair Display is being upgraded to include an optical size axis of 5pt to 1200pt.
It also includes a weight axis, a width axis, and italics.
Depending on increments used you could have hundreds of static fonts.

Science Gothic (a Bank Gothic revival) has four axes: weight, width, optical size, and contrast.
They had some discussions about how they could end up with thousands of static fonts (or variable instances) depending on the increments used.
That is with just four axes.

Roboto Flex has 13 axes.
If you used an increment of just 10 for each axis, that would be 10¹³ static fonts.

Additionally…
What is the proper increment for the Mutation (MUTA) axis in static fonts?
Or for the Gravity (GRVT) axis, or the Horizontal Rotation (HROT) axis, etc., etc.?
So far I have documented 59 different variable axes.
And many of those variable axes simply do not fit in a simple incremental pattern.

All of these pre-determined static fonts may not be "just right."
Variable fonts enable the designer to get exactly what they want, or require.

 

Link to comment
Share on other sites

9 hours ago, walt.farrell said:

the PDF format does not support Variable fonts. Essentially, any app creating a PDF needs to create a static version of the subset of characters used in the PDF, and embed that newly created static font subset into the PDF.

The PDF does not know, or care, if what is embedded came from a variable font.
The "PDF format" does not need to "support" variable fonts.

If an application can create and display characters/glyphs (shapes) from a variable font,
the application can also embed those characters/glyphs (shapes) in a PDF.
Just like alternate glyphs for character variants, ligatures, or swashes, etc., etc.

And what they call that embedded font does not matter.
The PDF does not know or care.

There is no limitation on the use of variable fonts because of supposed PDF issues.
It works now.

Link to comment
Share on other sites

17 minutes ago, kenmcd said:

There is no limitation on the use of variable fonts because of supposed PDF issues.
It works now.

Doesn't that require converting the fonts to Curves?

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

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

19 minutes ago, walt.farrell said:

Doesn't that require converting the fonts to Curves?

To test it, I saved a page in the latest version of Illustrator to PDF. The page contained several variable fonts in various configurations of weight and width axis settings. It worked fine. Furthermore, I opened the PDF in Illustrator and the variable fonts were still there, still useable and hadn't been converted to outlines.

Link to comment
Share on other sites

25 minutes ago, CoryM said:

To test it, I saved a page in the latest version of Illustrator to PDF. The page contained several variable fonts in various configurations of weight and width axis settings. It worked fine. Furthermore, I opened the PDF in Illustrator and the variable fonts were still there, still useable and hadn't been converted to outlines.

Thanks, but then why do sites like https://www.daltonmaag.com/variable-fonts say 

Quote

Yes, but the software producing the PDF has to convert the variable font to a legacy format or generate each static instance.

And are you sure that Illustrator didn't do that?

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

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

3 hours ago, walt.farrell said:

Thanks, but then why do sites like https://www.daltonmaag.com/variable-fonts say 

And are you sure that Illustrator didn't do that?

A Google date search tells me the page you referenced was published July 20, 2019. I suspect that's the reason. Much has happened in terms of Adobe's support of variable fonts in the last three years.

The variable fonts displayed perfectly in the PDF I made. Just to be sure, I emailed the PDF to my Android tablet that has no variable fonts installed and opened it. The type displayed perfect there too. I had intentionally set the width and weight axis of the glyphs to be in between the variable fonts' static versions, the PDF carried those intermediate values over perfectly to my tablet.

As I mentioned earlier, when I open the PDF in Illustrator, the variable fonts are there, have the right combination of width and weight axis, weren't outlined, and hadn't been converted into static fonts. Using Illustrator, I'm still able to adjust the width and width axis.

That said, editing the variable text within Acrobat (which I almost never have a need to do) is a problem because Acrobat apparently doesn't directly support editing the variable fonts yet. However, it displays and embeds them without a problem.

This thread has headed off on a tangent. The real point is that, for whatever reason, Serif has not incorporated variable font technology into their Affinity suite, which for some of us, makes using their products much less useful and is keeping us tethered to Adobe until they remedy the situation.

Link to comment
Share on other sites

18 hours ago, fde101 said:

I would argue rather that it should be the responsibility of the font manager within the underlying operating system or windowing system to do this.

Sure, for the general purpose of displaying text in a window by software like word processors, web browsers, and such. But the system is not responsible for the extra needs of design software that offers the ability to convert text to paths. It is up to the software to either program it in or to use a third party library that already does it.

In any case, it is not up to the font designers to do that job for them. There are numerous fonts by numerous designers. There are only a handful of specialized design software programs.

Link to comment
Share on other sites

5 hours ago, AdamStanislav said:

But the system is not responsible for the extra needs of design software that offers the ability to convert text to paths

No, but it could easily provide a consistent API to obtain a copy of the font's outlines which the software can use as a basis for implementing that feature.  Those outlines could already be compensated to match the variables, as the OS/font manager would need to do this anyway when rendering the font on behalf of other software.

This would still give the design software the benefit of not needing to duplicate the functionality that the OS already needs to do internally anyway, and leaves the more specialized aspects of the work to the application.  It also allows the operating system to implement support for newer (or older for that matter) font formats and the application could take advantage of them transparently.

Link to comment
Share on other sites

But I wonder what’s your point, @fde101. All three operating systems (macOS, Windows, iOS) already support variable font rendering and offer the respective APIs, and the Freetype project provides a freely available cross-platform software library to render variable fonts. Personally, I’ve never heard what @DamienG said, namely that the Affinity apps would already use Freetype. I doubt they do, for they would probably have been able to add variable font and color font support already, if they did. It would be interesting to hear from a developer about the text layout engine currently used in the Affinity apps or receive any comment on this thread. Everything is just speculative to this point.

Link to comment
Share on other sites

Here’s a hint at the underlying technology:

 

I guess that is to say that the (supremely fast!) screen renderer that is used by the Affinity apps requires a custom text engine that does not rely on the operating system or on third-party libraries for the core business of text layout and rasterisation, but reads font data directly from the binaries.

Link to comment
Share on other sites

17 minutes ago, A_B_C said:

Personally, I’ve never heard what @DamienG said, namely that the Affinity apps would already use Freetype. I doubt they do, for they would probably have been able to add variable font and color font support already, if they did. It would be interesting to hear from a developer about the text layout engine currently used in the Affinity apps or receive any comment on this thread. Everything is just speculative to this point.

While there's nothing definitive that they use Freetype for their rendering the Affinity About dialog "Third party licences" link has two entries for Freetype (admittedly they could be sub-dependencies and not used directly but a lot of cross-platform apps use Freetype as it's very powerful and rendering TTF/OTFs directly without a good library is more complex than most engineers would realize)

image.png.7e346165e6611ce7e8e4f7cd45e5d082.png

Link to comment
Share on other sites

  • 5 weeks later...
On 12/19/2022 at 3:13 PM, walt.farrell said:

Doesn't that require converting the fonts to Curves?

No. Not like "convert to curves" which makes it all simply shapes.
The text is still text.
Text is character data and shapes linked together.
Like any text, the shape associated with the character data can change.
Just as the character shapes change with various OpenType features.
Same character data, but the shape embedded is different.

PDF was not/is not designed for editing.
So the similar to the issues you have trying to "round-trip" OpenType features
you have issues trying to round-trip variable fonts.
I assume Adopey is doing the same thing they do with OpenType features - hide the settings in a "non-standard" encrypted section in the PDF.
Adopey and others have proposed various naming schemes for the embedded font names to enable recreating the variable settings.
Fine for just width and weight for example.
But that can quickly get kinda crazy with multiple axes.
So my guess is Adopey is hiding that too now.

But, PDF was not/is not designed for editing.
It has sort of evolved to do that more, but to work well that relies on adding non-standard data for the round-trip (which is why Adopey did it with OpenType).

PDF is not "designed" to support OpenType.
But fonts with OpenType features are used in PDFs every day.
PDF is not "designed" to support variable fonts.
But variable fonts are used in PDFs every day.
PDF is not "designed" to support color fonts.
But color fonts are used in PDFs every day (and color emojis).

The notion that because a PDF cannot be flawlessly edited prevents using any of  these features is simply not true.

 

Link to comment
Share on other sites

8 hours ago, kenmcd said:

PDF is not "designed" to support variable fonts.
But variable fonts are used in PDFs every day.

From what I've read, that is only because the applications using the Variable fonts create static subsets and embed those subsets into the PDF file.

But perhaps everything I've managed to find about that has been wrong, I suppose.

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

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

14 hours ago, walt.farrell said:

From what I've read, that is only because the applications using the Variable fonts create static subsets and embed those subsets into the PDF file.

But perhaps everything I've managed to find about that has been wrong, I suppose.

Well, sort of ...
There is no difference in sub-setting vs. not sub-setting (of the character set).
Works the same way.

When you embed sub-setted static fonts sometimes you may notice the font name multiple times with different prefixes of random characters - each of those is a mini static font. How this is done depends on the PDF library used to create the PDF. Different PDF libraries often embed the same fonts for the same doc very differently.
So creating a "static sub-set" is SOP.

Anytime you embed a font you have text character data and shapes.
That does not change with variable fonts.
If I select a pre-defined named instance from a variable font (such as Medium), the shapes embedded will match the static Medium font.
The font name embedded from the variable named instance may also match the static font name.
Depends on how the variable font is constructed.
Google Fonts makes their variable fonts so the named instances are interchangeable with the statics (generally).
The downside to that is if both statics and the variable are installed they may have name conflicts.
Commercial font developers usually name the variable and statics differently to avoid the name conflicts.

When the names are the same the PDF does not know that the pre-defined variable instance embedded (e.g. Medium) was not a static font. The shapes may have been computed from the variable font, but they are the same as the static shapes.
So looking at the finished PDF you have no indication of the source being variable or static.
You have embedded FontName-Medium, and the same text character data and shapes.

When you select custom axis variations, then you have a font naming issue to deal with when embedding.
There is not a simple list of 10 weights, or widths to select the font name to embed.
Adopey has published their recommended naming guidelines for these custom-settings embedded fonts.
And there are some other competing recommendations from some others.
But embedding the text character info and shapes is still the same.

 

Link to comment
Share on other sites

Thanks for that description, @kenmcd. From it, I would say that variable fonts do not "just work" in PDF files, which was my point. What you have in the PDF is a constructed static font (or set of them), and the methodology of getting them there is significantly more complex than for static fonts.

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

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
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

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.