kenmcd
-
Posts
1,713 -
Joined
-
Last visited
Posts posted by kenmcd
-
-
13 hours ago, mopperle said:
Finally I was able to finfd a link to the "old" Windows 10 Package on Microsofts forum:
Didnt installed it so far, but after a look at the content of the cab file, it looks as if there are not so many variations as with the Windows 11 package.
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." -
15 hours ago, Alfred said:
Is the Windows 10 version of the font pack available to Windows 11 users?
Lots of people have both Win10 and Win11.
And there those like me who back-up all the supplemental font packs. -
9 hours ago, mopperle said:
Neue Haas Grotesk"
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. -
On 4/20/2024 at 8:42 PM, JGD said:
there can certainly be ways of making Colour-SVG fonts support variable axes.
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.
On 4/20/2024 at 8:42 PM, JGD said:that same philosophy could be applied to the format and turn colours, and maybe even texture and gradients, into editable “axes”
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 converted the Win11 Segoe UI Emoji font to COLRv1 a few months ago. So 100% perfectly scalable with gradients.
Update Note: an article said the new font had both the v0+v1 formats. But I just dumped the COLR table and it only has COLRv1. So I am not sure how Affinity is currently handling that emoji font on Win11. Guess going forward Affinity is going to have to support COLRv1 to still support color emojis in Win11.It's very late here. I'm rambling...
Hope when Affinity adds variable support that it also includes at least COLRv0 variable.
-
4 hours ago, Bobby Henderson said:
It's surprising finding overlaps in static fonts (note, I've seen these overlaps in static versions of Roboto Serif and Roboto Slab as well as the sans Roboto).
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.
-
8 hours ago, 4dimage said:
For compatibility reasons with current web projects i installed the 18 "static" font styles
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. -
7 hours ago, 4dimage said:
This doesn't seem to be an affinity bug, but rather due to the way certain letters in variable fonts are constructed. Instead of the usual compound paths, the letters consist of individual shapes that only visually merge into an overall shape through overlapping.
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.
-
2 hours ago, JGD said:
There's a lot of interesting stuff there, including, incidentally, a new “colr” table for colour fonts…
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-issuesFuture 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-fileThey 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.
-
2 hours ago, anto said:
I did an experiment and used the dictionary from Indesign to the same text. (For clarity, I installed the LibreOffice dictionary for 2.4.2 and the Indesign dictionary for the beta version, and opened the same document.) The Indesign dictionary did a much better job, even though the settings were the same.
So what was the problem? Is it the dictionary or Publisher's incorrect use of it?Are the two hyphenation dictionaries the same?
Did you compare them?
Sounds like the ID version has been improved. -
1 hour ago, pisksix said:
As I clearly stated, I want to be able to remove the password, or at least change it to something which is not 15 characters. The passwords are never the same, and cumbersome to remember.
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.
-
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?
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?
-
4 hours ago, philipt18 said:
While we're on the topic, I just noticed something odd and I don't know if it's a font issue, or a Publisher issue. Using the same font, there is a section in my text where it says Esq. however the text is in small caps. The q in Esq. takes on the alternate form (which stretches the line of the Q under the next letter) even though Contextual Alternates isn't selected. It's only when the q is in small caps that this happens. It's all-caps there isn't a problem.
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.
-
14 minutes ago, RaeH said:
The very first font style I download (for example "FilsonProBold") I get an install option. I don't get the "there is already a version installed" notice.
But, after the first one, it's like they are seeing "FilsonProBold" the same as "FilsonProBook" and "FilsonProLight" etc...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).
-
1 hour ago, RaeH said:
When I am downloading each style, Font Book tells me that "A version of this font is already installed", so I select "Keep both". I've had to do this in the past I believe with other fonts and all the styles still work.
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.
-
30 minutes ago, RaeH said:
Thank you! Unfortunately I'm still having the same problem after clearing the cache, removing the fonts and re-downloading.
Did you shutdown and re-start Affinity? It too has to rebuild its font cache.
If it still does not work, make sure you do not have multiple versions installed. And make sure there is only one file for each font - the same files should not be in your user fonts and in the system fonts.
If that does not work - I am out of guesses.
-
1 hour ago, RaeH said:
It seems as though I am having the same issue with the Filson Pro font.
...
Here is where I downloaded it, although I have tried various places
https://font.download/font/filson-pro#google_vignetteI would like to have ALL styles to work with at once in Affinity Designer.
Is there a work-around?That particular version appears to be OK.
There are versions of Filson Pro floating around out there which are really bad.
So if you had installed those first, you may need to clear your font cache.After checking them..
I installed the versions above and all are listed in Affinity Designer v2.4.1 on Win10.
So they appear to be fine. -
Did some testing, and it definitely does not work 100% with all Khmer fonts.
But some may work.
Out of the four Khmer fonts in Google Fonts, two appear to work with your test text.
Different fonts use different OpenType features in different ways to create the text.
So one of them may work for you now.In Affinity Publisher v2.4.1...
Khmer and Konkhmer Sleokchher appear to work with that text.
Noto Sans Khmer and Noto Serif Khmer did not.
I also looked at the three Khmer fonts that come with Windows.
None worked with that text in APub.So that Khmer font from GF may work for you for now.
You will need to test more thoroughly.
There may be other character sequences which do not work properly.
Please let me know how your tests go with those fonts.Obviously more work needs to be done to properly support all Khmer fonts in Affinity.
-
Please paste your test text here.
I would like to do some testing and want to be sure I have the correct characters, and in the correct order.
-
45 minutes ago, GenewalDesign said:
But why this problem is only in Windows and not in MacOS?
For me - don't know, don't care. The fonts are purposely broken junk.
You should read through the longer explanation posts in the linked thread.
Different applications and different operating systems have different text shapers, etc.Given the edge case here - of purposely broken multi-mapped demo fonts - I doubt the Affinity developers would prioritize this issue over many other far more important issues.
Would be surprised if this gets "fixed" any time soon, if ever. -
19 minutes ago, Alfred said:
This issue is also tagged as AF-1541:
Probably the same issue (excessive multi-mapping).
But I never did get a look at that particular font.
It is mentioned that it is "an all caps font" so it could have the same multi-mapping to the lowercase characters like these ones.I looked at the three KC Leisure Park fonts, and many others from the same developer in a pack of their "free" fonts (61 fonts).
Wadda mess.
Does the same thing as the fonts in the other thread I linked to - when butchering his fonts to make the free versions, he multi-maps all the glyphs he has removed to the base character.
So Aacute is mapped to A, and Agrave is mapped to A, etc., etc.
Sleazy.
And dumb. -
This appears to be the same issue as AF-1541.
See: https://forum.affinity.serif.com/index.php?/topic/195968-font-rendered-and-exported-differently/Another case of a font created with Fontself Maker with excessive multi-mapping.
The problems with excessive multi-mapping are discussed in the above thread.So basically the problem is in the fonts.
Yes, some other applications may handle this, but creating fonts like this is just dumb.
Which is why Adobe strongly discourages it, and Google Fonts outright prohibits it. -
Are any of the fonts from Google Fonts color fonts?
If yes, which fonts?
-
The OpenType setup is a bit odd.
That alternate one is only an alternate of the lining figures one character.
It does not appear anywhere else - which is odd.The default figures are proportional oldstyle.
And that alternate one is taller, because it is for the lining figures.
Normally you would have also have a shorter alternate to match the oldstyle figures.
So it may look a bit odd if you do not make all the figures lining.But, you can get directly to that single character.
The developer did assign Unicode code points to all alternate characters.
The code points are up in the PUA (Private Use Area).
That alternate one is assigned to U+E433.Another option - the lowercase dotless i looks like a one.
And it looks the same height as the default oldstyle figures.
It is at U+0131.
This would be my choice for running text.Warning: the name fields in those fonts are big mess (looks like a bomb went off).
So if you have them all installed - weird stuff may happen.
Only install the exact fonts you are using (to try to avoid name conflicts).
And you may avoid issues.
Check your PDF output to make sure the correct fonts actually got embedded.If you have issues, and are only using a few of the fonts - I can make you a set which will work without problems.
-
The Windows 11 color emoji font recently added the COLRv1 format in addition to the existing COLRv0 format (which Affinity does support currently).
So it is only a matter of time now until an Affinity user asks why their color emojis do not look the same as in other Win11 apps (e.g. Word) which display the COLRv1 versions.
Supporting COLRv1 would solve that issue - and this one.
Please make a note to the devs in AF-2609.
[Windows 11] New Font not correctly displayed
in Affinity on Desktop Questions (macOS and Windows)
Posted
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....