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

kenmcd

Members
  • Posts

    1,635
  • Joined

  • Last visited

4 Followers

Recent Profile Visitors

4,668 profile views
  1. That is because the version you have does not have a Default in the OpenType scripts. You must have v7.504 or earlier. Some OpenType features are appropriate for all scripts. So those are usually put in the Default - to always be available. Milo OT v7.504 does not have Default, it only has Cyrillic, Greek, and Latin. Milo Pro v7.600 (now from Monotype) does have Default. So when you select Language None, the OpenType features such as alternate figures are still available. And you will notice that in the Typography Script drop-down there is also Default, in addition to Cyrillic, Greek, and Latin. Auto is matching the Typography Script to the selected Language script. So when you select Language as None, there is no script to match for Typography. This is where the OpenType Default (script) features would then take over. Question: Out of curiosity, what is your use case for this? I will sometimes set language to None when there is a bunch technical stuff which just makes the spellcheck go crazy. What prompted you to turn-off the spelling check?
  2. No, there is not a limitation on embedding with COLRv0 fonts. How it gets embedded depends on what the application does, and the PDF library. LibreOffice - both Gilbert COLRv0 and Patriotic COLRv0 embed just fine, as Type3 with Custom encoding, and it can be edited in color, and you can copy the text and paste the text into a text editor (so the ToUnicode is correct). So my keyboard input is mapped to the COLR table glyphs. Word - both Gilbert COLRv0 and Patriotic COLRv0 are embedded as TrueType (CID) with Identity-H encoding, and when you edit it is black not color, copying text does not work at all (so ToUnicode appears to be non-existent). So my keyboard input is mapped to the black glyphs in the glyf table. I got a different results when printing to various PDF printer drivers. Each application is different. What happens when you edit depends on how the characters & glyphs are mapped. How well the application does this. And how the font is constructed. And how well your editor connects the mapping, and works around deficiencies. Not some embedded fallback. Affinity appears to "punt" and just embed the shapes, with no text info.
  3. Still not sure what you are trying... but it sounds like you have multiple versions installed, and that is most likely the issue (the corruption). The original Gilbert Color is only Color-SVG with PS outlines backup (.otf). There are some conversions available for COLRv0 and COLRv1 (with SVG also) which do have conflicting names in them. The conversion tool does not typically fix the names. So if you have a bunch of those installed you will have name conflicts. In the COLRv0 font I posted above, I fixed the names manually using ttx. So it should have no name conflicts. As far as how the font is embedded, or the image, that is up to the application. And I am not sure what you have tried with what application and what font. Additionally some of the fonts have multiple formats in one font, and this may confuse some applications. Or the application may just embed an image for some formats. The original Gilbert Color SVG does not have anything in it which requires COLRv1, so I am not sure why anyone would include that - just confuses things more. The Patriotic font I converted presently has COLRv0, SVG, and TrueType in it. Not sure if I should leave the SVG in there, the safe bet is to delete it. Some smarter applications will use the "best" format for their needs. Some dumber applications will see it has an SVG table, and quit, even though there are two other formats in the font which it does support and could use instead. Affinity appears to be smart enough use the COLRv0, and ignore the SVG. To check a particular embedding issue, need to see the specific font.
  4. Gilbert Color COLRv0 Font Converted from original Color-SVG to COLR v0. Has TrueType outlines as monochrome back-up (i.e. black). Displays in APub as color. Exported from APub to PNG and PDF in color. Gilbert.Color.COLRv0.zip Note: this is a free font (has a CC license in the font). Example: Export to PNG from APub.
  5. Conversion to COLR seems to be working... sort of... This is Export to PDF from APub and then converted to an image. I got some errors on the conversion, and that seems to be related to some of the details (the lines etc.). Gotta go now - will check it out tomorrow. Note: bonus side effect is all the SVGs have been dumped to a folder.
  6. Wow. This may actually be convertible to COLR. Most OpenType-SVG fonts just contain images (which cannot be converted), but this appears to have vectors - so it may be possible. We'll see.
  7. You may be able to convert the font from SVG to COLR (which works in Affinity). Depends on the SVGs in the font. Have to see the font.
  8. Free OFL alternatives are another option. Libre Caslon Text - https://fonts.google.com/specimen/Libre+Caslon+Text
  9. ACaslonPro-Italic and Adobe Caslon Pro are probably old conversions from PostScript Type 1 fonts (or actually are old Type 1 fonts). And thus have limited character sets and features. So you can use Find & Replace to permanently replace those fonts with the other Caslon fonts you do have.
  10. You can use the Glyph Browser to select any glyph. But your font may also have OpenType features which give access to the alternate forms. Highlight the text and then take a look at the Typography Panel to see available features. What font is it?
  11. Bebas Neue only has five. GT America has 84. But they both have a similar way of configuring styles. I assume the six in the screenshot are the six separate styles used in the document - six styles of those 84 styles. Do not see how they could be sub-families
  12. What font are you using? You mention "OpenType styled superiors" so I assume you are using OpenType Superscripts applied from the Typography Panel, and that the font supports this OpenType feature, and the font has the proper glyphs, and actual kerning pairs for those substitute glyphs. Not a lot of fonts have full OpenType superscript lowercase support (with substitute glyphs). And even fewer have the full actual Unicode superscript lowercase characters. All of these could be interacting with what Affinity is doing with the superscripts. And if you have used the Transform panel instead, or mixed that in... It would be helpful to see an actual document, and the resultant PDF.
  13. Did the correct fonts end up in the package? The Package Fonts list only shows the family name, not the styles. So it appears to be confused about the names at some point. Confused when putting the fonts into the package? or Confused when trying to get the fonts from the package? The GT America super-family has a particular names/weights/styles configuration that may be confusing Affinity. One of the old Bebas Neue families has a similar structure and it has been the source of some other fonts confusion issues. And it only has five fonts, not 84. What are the six fonts/styles you actually used? Maybe I can try it here. Do you have all 84 fonts installed on the source machine?
  14. Most search and/or spell-check apps understand that the fi (U+FB01) single character ligature is the same as f+i - two separate characters. And they work either way. Same with the other legacy ligatures which have a single code point. So your request is not that odd. Some apps may already do this for œ etc. Same thing happens with characters with/without the accents. Many apps accommodate it either way. Note: if you look in the spellcheck dictionary files used in Affinity apps you can see how they handle the ligatures.
×
×
  • 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.