Feature Proposal: Document Font Management

[Thomas Ganter]

Hello world!

I do publishing as a hobby. Pro bono as a volunteer for parishes and communities.

But as a result of that I have many different established "identities" to support, all with their own Colour Schemes, Layouts and typography.

Colour Schemes and Layouts I can manage using Paletes, as can I typography  --  but not associated fonts.

 

Current solution is to either have all fonts always installed on the system.

This is a mess, and it slows down my system and makes the font dialogs unwieldy.

 

Alternative is using a font manager.

This is also a mess, since none integrates well with Publisher and it is a painful manual exercise every time.

 

Also, both solutions are not "portable" in the sense of "trans-portable".

 

Thus, after long intro, here my proposal:

Make Fonts "importable" like any other asset.

Just import document fonts and make Publisher (and the other Affinity Studio applications for that matter) retain the font files in the document bundle so they are sent along onto other platforms. And they are automatically enabled when the document is open. And automagically do not show up anywhere outside the document.

 

Clean, simple solution.

Transparent to the user.

Failproof.

Robust.

Intuitive.

 

Community  --  what do you think?

Greetings,

--Thomas

 

[Wosven]

Or, instead of embedding fonts, do the same as ID: the app can import fonts if they are in a special folder named "Document fonts" and placed with the document. It's really helpfull, especially when needing to open archives on an external hard drive or from a server. You open the file, copy what you need, modify, etc., close the file and it's done without complication. 

[Wosven]

And another usefull feature would be for the apps (AP, AD, APub), to be able to hightligh missing fonts (no fonts manager in AD or AP).

[Thomas Ganter]

9 hours ago, Wosven said:

the app can import fonts if they are in a special folder named "Document fonts" and placed with the document

d’accord.

I was thinking about this as well – there's the PRO and CON to weigh with Assets.

That approach would be obvious (and should be supported in parallel!) but then there is always the chance of just missing to send those documents along when sharing the file. Also, there is always the Font license issue  --  having the fonts in plain sight makes piracy so much easier (don't want to use the word „encourages“ though).

Having fonts embedded could be a one-way route (i. e. not make them "exportable" again) and all rights are maintained (assuming you have a license for the font in the first place).

But, for the avoidance of doubt, a "document fonts" folder should be supported as well.

 

[Wosven]

4 minutes ago, Thomas Ganter said:

missing to send those documents along when sharing the file

A proper workflow is to "archive" or whatever it is called depending of the apps, that means after a work is finished, exporting to a new folder in which resources will be properly copied in subfolders: images (if linked), fonts, and extra data (for print, for font kerning, etc.).

When people only send/share the main file, it's a pain and an error… but after working a long time doing this, I keep hoping they'l learn to do it properly (or they'll be pestered until they do it properly!)

10 minutes ago, Thomas Ganter said:

having the fonts in plain sight makes piracy so much easier

On my last year on Mac, it was nearly impossible to copy fonts when needing to give a work to a coworker, etc. There wasn't piracy involved but work and people installing only a limited amount of fonts for performance purpose. It end up with us creating a shared folder on a server with all the fonts so we could find the missing ones easily. Sometimes, hiding or prohibiting actions are worst when it's complicating a workflow.

17 minutes ago, Thomas Ganter said:

Having fonts embedded could be a one-way route

Perhaps there would be complication for Affinity with this? And what happen when a font is bugged or in conflict with installed font? Would this font be available automatically for AD or AP if we need to create a new file with it? And if we need this font to be installed for working in the document (or it wouldn't display), should we search manually and send the fonts too?

If fonts are embedded (and don't need an installed file), can we simply copy some text and paste it in a new document to keep on using this font?

 

Fonts can be a problem usually, but I'm worried it would be worst with embedded fonts.

[Catshill]

I agree. The place option should imho use the embedded fonts. Opening a pdf directly should offer options to use embedded fonts or replacing them. This is Publishers biggest failing for me. 

[garrettm30]

On 8/30/2019 at 3:56 PM, Thomas Ganter said:

Alternative is using a font manager.

This is also a mess, since none integrates well with Publisher and it is a painful manual exercise every time.

 

(This is more of a side-note, not intended to take away from the main request.)

I have had pretty good results with Typeface. If you have a Mac, you might consider giving it a try, as it is fairly low-cost.

As soon as I activate a font in Typeface, it is automatically available in Publisher. I also have it set up to auto activate, and that generally works well, but not perfectly. For example, if I open a Publisher document that uses a font that is not currently active, Publisher still will give the notice of the missing font even though Typeface will immediately make the font available for use in Publisher without activating it. I think the notice happens faster than Typeface has a chance to make the font available. However, that is just cosmetic, and the font does become available in Publisher right away.