kenmcd

Nope. The only fonts available from the cloud fonts are the basic RIBBI v1.05. Not even the Medium. And certainly not all of the 16 styles in the variable. The cloud fonts are kind of a mess. When I started doing a detailed inventory awhile back I found stuff missing, old fonts, misnamed fonts, etc., etc. Definitely a WIP. The lack of the Medium for the old static version is probably an oversight. But the lack of all the styles from the variable is likely a decision. Probably not what you wanted to hear. But variable font support is coming to your favorite Affinity app soon....

That is the older v1.01 from 2015 - only had four fonts (RIBBI). The two Medium were added in 2017 (v1.05). What version of Office do you have? You should be able to get all the font styles from the variable font from the cloud fonts. And the cloud fonts are all static. Hmm... let me check the cloud fonts json file to see if they are in there. If they are, then Office can be coaxed into downloading them. Office 2019, 2021, and 365 should all work. It should have the six styles at least, and maybe all 16 like the variable. Lets check... "I'll be back."

Lots of people have both Win10 and Win11. And there those like me who back-up all the supplemental font packs.

That family was changed in Windows 11 to be a variable font. If you get the Pan-European Supplemental Font Pack from Windows 10, the fonts are still separate static fonts - so they work in Affinity now.

The current SVG table format does not support it. So at a minimum that would have to change - or a new table added. SVG has some advantages but COLR is adding those. Similar to... the current CFF table for OpenType-PS fonts does not support variable - so they added a CFF2 table to be able make variable OTF fonts. But one of the things in the boring-expansion-spec is to be able to put PS curves in the glyf table where the TT curves are now. So the OTF variable fonts may end-up being an Adopey-only thing and not catch on widely. That is being discussed for COLRv2. And perhaps images too (so virtually all SVG advantages would be gone). Behdad posted a summary of the ideas for COLRv2 in the colr-gradients-spec repository on GitHub. SVG fonts are not likely to go away any time soon. They are easy to make and also support a monochrome fallback. SBIX does not have that fallback. Hopefully it will go away. CBDT - Google put that out to pasture in favor of COLR. COLR is the future of color fonts. COLRv0 is stable. COLRv1 is still being tweaked, fixed, and added to. But people can and are making COLRv1 fonts now, both static and variable. You download them from GF, and there are some others in GitHub, and you can find them more and more in places like CreativeMarket, etc. Once COLRv1 is stable then the focus will turn to COLRv2. Color-SVG fonts which are only vectors can fairly easily be converted to COLRv0 and COLRv1. The COLRv0 fonts already work in Affinity. We tested quite a few. Hopefully Affinity will add support for COLRv1 - the sooner the better. Microsoft added COLRv1 to the Win11 Segoe UI Color Emoji font a few months ago, in addition to the existing COLRv0. So 100% perfectly scalable with gradients. Only a matter of time now until a user asks why the emojis do not look the same in Affinity (COLRv0) as they do in their other Windows apps (COLRv1). It's very late here. I'm rambling... Hope when Affinity adds variable support that it also includes at least COLRv0 variable.

This is typical of GFs own fonts. But for most fonts the upstream repository is going to have static TTF fonts without overlaps. And OTF fonts too. OTF static fonts never have overlaps, so that is the easiest work-around. And you can remove the overlaps yourself - I used FoundryTools-CLI (in GitHub) to remove the overlaps on the Roboto Condensed fonts above. And you could use it to convert the TTF fonts to OTF fonts.

Here try these - the overlaps have been removed. Roboto.Condensed.v3.008.(2023-10-19).from.GF.overlaps-removed.zip Note: Removing the overlaps also causes the hinting to be removed (because the shapes change). This could be added back by running ttfautohint if you desire.

The Roboto Condensed static fonts still have the overlaps. Most of the time font developers will remove the overlaps when the static fonts are created. But some of the GF tools do not remove overlaps by default. Developers using their tools can switch-on "remove-overlaps" and usually do. But since being able to properly handle overlaps is required when using GF variable fonts, GF will often leave-in the overlaps. If you are on a Mac, Core Text did/does have a rasterizing issue when two lines are on top of each other - it shows a bit of a halo where the overlap is. Do not know if this has been fixed or not (probably not). But the big jaggies you are seeing are an Affinity issue with the overlaps. They are going to have to solve dealing with the overlaps to support variable fonts. Variable fonts are never going to remove the overlaps. Note: As a work-around for now, you can remove the overlaps from the Roboto Condensed static fonts yourself.

The COLR table was added in OpenType 1.7, in 2015, (for the COLRv0 format). The COLRv1 format was added in OpenType 1.9, in Dec. 2021 (so that part is newer). Color fonts using either COLR format can be variable. Color-SVG fonts cannot be variable - so they really do not belong in this discussion. Proposed changes and updates to the OpenType spec can be followed on GitHub. Here: https://github.com/MicrosoftDocs/typography-issues Future font technology is also being developed on GitHub, and in an ISO group. The code development and specs are here: https://github.com/harfbuzz/boring-expansion-spec?tab=readme-ov-file They have been interacting with the ISO for developing the Open Font Format specification. There is a newsgroup set-up by the ISO where this is discussed. Note: the Open Font Format will actually be open, unlike other ISO "public" standards which must be paid for (people made a lot of noise) so you can download the current version from the ISO "free" standards page. No patents involved as far as I can tell.

Are the two hyphenation dictionaries the same? Did you compare them? Sounds like the ID version has been improved.

Depends on what they have done to it. An Owner password is easy to remove. A User password is not. Do you have to enter the password to even open the file to view in a PDF viewer or editor? If Yes, that means there is a User password. With a User password they may enable viewing and printing, and at the same time disable editing. When you open the PDF in Affinity it is being opened to edit. If it has an Owner password which is set to prevent editing, that is easy to remove. Some tools may be able to reset or delete the User password, once opened. I have seen the claims, but have not tested this (have not had the need to). They may also Sign or Certify the PDF which means it requires the related certificate to change or edit. I have not seen any way around these (and I've tried). (very annoying when scans of 300 year old documents are signed - so you cannot even add bookmarks) PDF viewers/editors will usually have a Security tab in the Document Properties which may show us what is in there. So a screenshot of that may be helpful. If you can print it, you should also be able to print it to a new PDF using a PDF printer.

@TheZBillDyl How many colors do you need for the fonts? It is easy to change the color palette in COLRv0 fonts (takes minutes). Affinity apps support COLRv0 fonts. And it is relatively easy to convert a monochrome font into a single-color COLRv0 font. So if you needed four colors you could have four fonts. Could you run your merge in four batches? @lacerto Any easy way to swap the font during the merge? --- Edit: Or any way to tag the incoming text so a style could be applied later?

The issue is in the font. Both the Small Caps and the Petite Caps only have the long-tail version of the Q. There is no short-tail version in either - there are no such glyphs available. So, some more odd stuff in there. I like the font. Kinda amazing what he has done with the tools being used. But it really needs a lotta love.

Those are not the names in the fonts you linked to above - which are not broken. Those are the names in one of the very broken versions I mentioned above that are also out there (which should be deleted and never used).

Cannot do this with Affinity apps. The OS keeps track of the "right" font files to use. But Affinity scans the font folders to build its font cache, so if you have duplicates installed... it causes issues like this. So, as I mentioned above, make sure you have no duplicates installed. Uninstall the fonts, then make sure there are no files for those fonts left in the fonts folders, then reinstall the fonts. You should not get any message about "a version is already installed." Shut down any Affinity apps before doing this. Then when they are restarted the Affinity font cache will be rebuilt without duplicates.