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

Search the Community

Showing results for tags 'opentype'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Affinity Support
    • News and Information
    • Frequently Asked Questions
    • Affinity Support & Questions
    • Feedback & Suggestions
  • Learn and Share
    • Tutorials (Serif and Customer Created Tutorials)
    • Share your work
    • Resources
  • Bug Reporting
    • V2 Bugs found on macOS
    • V2 Bugs found on Windows
    • V2 Bugs found on iPad
    • Reports of Bugs in Affinity Version 1 applications
  • Beta Software Forums
    • 2.3 New Features and Improvements
    • Other New Bugs and Issues in the Betas
    • Beta Software Program Members Area
    • [ARCHIVE] Reports from earlier Affinity betas

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Website URL



Member Title

Found 18 results

  1. Case-Sensitive Forms are an OpenType feature designed to replace some glyphs with alternates when All Caps is applied. (Official description here.) Activating Case-Sensitive Forms (a checkbox in the Capital section of the Typography window) should have no effect except when All Caps is applied, but currently Case-Sensitive Forms is replacing relevant glyphs whenever the feature is activated regardless of case. In the examples illustrated here, Case-Sensitive Forms include and upward shift of hyphens and parentheses for Abril, Lygia, and Albertan and a switch from oldstyle to lining numerals for Abril and Lygia. All of these behaviors are correct in the right column where All Caps has been applied but incorrect in the left column where case is unchanged. Additionally, activating Case-Sensitive Forms forces capital letters from Lygia. I suspect that there is something different and/or wrong with Lygia’s coding but note that it would likely not matter if Affinity’s handling of Case-Sensitive Forms were correct. Additional notes The same examples exported from Adobe InDesign 18.0 is included for comparison. As far as I know, it is not possible to turn off Case-Sensitives Forms in that program. This issue to be affecting Publisher v1 as well, but I think it might be a new issue. PDFs I have exported more than a few months ago do not show this unexpected behavior, but I’m having trouble finding definitive evidence that I had Case-Sensitive Forms turned on at that point. Minor nit: ‘Case-Sensitive’ should be hyphenated in the Typography window.
  2. The issue Some OpenType stylistic alternates (ssNN) are generically named despite them having a descriptive name. The first screenshot shows the stylistic alternates for the roman on the left, and the italic on the right. Notice that the stylistic alternate number is only used in both styles when they have exactly the same name, otherwise they skip numbers so not to collide the other style. (I don’t know if that is relevant to this issue but it bears mentioning.) The second screenshot is showing how "Stylistic Set 02" is generically named in this sub-heading style. The sub-heading style is roman, it doesn’t have a "Stylistic Set 02", only the italic does. Yet it still shows "Stylistic Set 02" as a part of the list of "Stylistic sets: …" Expected behaviour I would expect the "Stylistic sets: …" selector of the "Edit Text Style" window to only show features from the font in question. In this case the Publisher style is roman, hence it should not show the "Stylistic Set 02" which only exist in the italic style of the typeface. Further, the "Stylistic Set 02" is the generic name which only adds further confusion.
  3. I am just wondering if the new designer V2 programme now supports the colour fonts (OpenType SVG fonts), as I will only buy V2 if it has this feature, as I’m very happy with Affinity Designer V1.
  4. Entering Tamil or Indic Unicode font text in Affinity apps has been a problem for a very long time. This simple Python script allows you to enter certain Unicode-based open-type .ttf Tamil font text data. It uses the fact that you can enter some of the open-type glyphs using the Glyph Browser in Affinity! Note: not all open-type or pure Unicode fonts will work with this program! Certain types of Unicode-based open-type Tamil fonts like Vijaya, Akshra, all TAU-encoded fonts and many more work fine. If the Tamil .ttf font file contains all the character glyphs, and they are also indexed in the GSUB table, this program will work. At present, this is program is hard-coded only for Tamil. It may work for other open-type Indic fonts, if you modify certain sections and give the correct Unicode data like the range, pre-appending, post-appending char lists etc. Note that the converted data is not a font file, but a string of glyphs that can be displayed correctly inside Affinity. You will have to fully reformat the text after the copy-paste. Also, you can’t change the font family of the pasted glyph text. It has to be converted again and pasted for the new font. But you can change the font size of the glyph, and do some minor editing using the Glyph Browser, etc. For more details, see the comments in the program. See the first sample screenshot that shows the Tamil text using the open-type vijaya.ttf font. See the second screenshot that shows the conversion of Unicode Tamil data to a string of glyph data. This glyph string data can be pasted inside Affinity apps and toggled to Unicode. This works only for certain .ttf fonts mentioned above. Check this simple Python TKopentypeTamil1 script on my cmathiaz Github page. Good luck. https://github.com/Cmathiaz?tab=repositories
  5. Would be nice if you could implement "palt" feature https://sparanoid.com/lab/opentype-features/#palt Additionally pwid/pkna/halt would be nice. https://sparanoid.com/lab/opentype-features/#pwid https://sparanoid.com/lab/opentype-features/#pkna https://sparanoid.com/lab/opentype-features/#halt East Asian Tetragrams (Chinese, Japanese, Korean) smpl trad tnam expt hojo nlck jp78 jp83 jp90 jp04 hngl ljmo tjmo vjmo fwid hwid halt twid qwid pwid palt pkna ruby hkna vkna Ultimately I would like you to add "Mojikumi" feature that's set of templates for kerning. https://helpx.adobe.com/indesign/using/composing-cjk-characters.html#change_mojikumi_settings
  6. Hi guys, I am experiencing a weird behavior of Publisher with a preproduction font that lays heavily on the contextual alternate Opentype feature. The problem: The font is valid and works fine in Indesign CC 2021 and the Typeface font manager as well as on fontdrop.info. However, when I turn on the contextual alternatives in Publisher, all of them are rendered except for the ones related to the lowercase "i" (like "is", "in" etc.) . See first screenshot for Publisher (blue), second for Indesign CC (black). I am able to reproduce the issue. Please note that I can only provide the font file directly to the support staff. Cheers, Johannes Latest version of Publisher macOS Mojave (latest) Hardware Acc.: On
  7. Hello, Are you planning on adding functionality for the new OpenType variable font technology in Designer, Photo and Publisher? Best, Bauke
  8. On opening the attached PDF file, OpenType Initial Forms are enabled for all text frames, but they are not listed in the OpenType Features, so cannot be turned off. Advanced Typography.pdf
  9. For instance, the below text:- (literally:- are you going this year, brother ?) is not rendered properly in both Designer and Photo. The area that I highlighted contains tone mark which is supposed to be a bit higher than the upper-level characters, However, they are placed at the same level, and clash with each other. This suggested that the OpenType GPOS table is not applied.
  10. I understand why you did it, ligatures lock text from tracking. I have designed a font where this is solved by changing f and l not by single glyph fl but by just chaning the f, as you can see in the atached picture. 1) user should have option to turn this off. If can, where can I do it? 2) it should be applied only on liga feature where two glyphs change with one glyph Thanks, Jan
  11. I've noticed that all the Affinity applications have trouble with the Contextual Alternates feature (on by default). The 'error' occurs when the entered text has an initial capital. Specifically when the applications auto capitalise the first word. All OK in Adobe applications etc.
  12. Affinity Publisher on Windows 7 (64bit, German) behaves as follows: Create a text with a font that supports several OpenType features like stylistic sets. The screenshot was done with 'TheSans E4s' by known font designer Lucas de Groot. With no OpenType feature used, the text always behaves properly. With certain OpenType features enabled, the metrics of corresponding characters become garbled, so that the resulting text is sometimes unusable. For reference, the screenshot shows shaded fields and blue text frames. Here some remarks concerning the image: The 1st and 2nd line use 'normal' text, and everything's fine. The 3rd and 4th line use 'ss11' and, by some mysterious reason, though both lines contain the same text, the line with the date field contains too much space behind the '1'. When checking the '1' in right-aligned text, the ss11 version suddenly doesn't have too much space behind it, but appears to have negative metrics at the right, so that it overlaps the frame. Checking the same with differently styled versions of the 'Q' character produces the same error: The 'normal' Q is correct, any of the styled versions has negative metrics. This definitely seems to be a bug in Publisher, because every other software I tried does this correctly. Affinity Designer also yields correct results (no additional white space, proper alignment). If Publisher and Designer use the same code base for OpenType support, please revert Publisher to Designer's correct behaviour. Andreas Weidner
  13. Sorry to nag about an esoteric issue that is probably of no concern to the vast majority of DTP users -- to me, however, it is highly important that the automatic typesetting of long s in Gerhard Helzel's open type fonts function properly - which is still not the case with build (win). If the automatic long s-function can't be implemented in Apub for some reason, I would have to continue to use Word, where this function works flawlessly, even as Word is rather clumsy to use in so many other aspects of DTP. But if this particular function works so well with Word, why can't it be done in Apub? Would seem to me that a skillful programmer could solve this quickly. However, as I am no programmer myself, I may be making an inference that is way beyond the scope of my knowledge, so please pardon me if I'm mistaken in this regard. https://forum.affinity.serif.com/index.php?/topic/67933-opentype-support/&tab=comments#comment-351320
  14. Please add support for OpenType locl feature - Localized forms. Currently you can switch the language of a text from the Character palette, but this doesn't trigger the locl feature. (This is how it usually works in Adobe apps) This feature is quite important especially for Cyrillic scripts. Tested this with Affinity Designer, not sure what is the case with Affinity Photo.
  15. The OpenType feature implemtation seems good and comprehensive. There seems to be a bug with OldStyle Figures. Using my Kabala OpenType Font I can enable the OldStyle Figures, and then revert to Default sometimes, but other times the option is greyed out. Again, after a while, the application crashes.
  16. Hi, I do you have plans to change the opentype display in Affinity Designer. At the moment you cant see does a font support Small caps / superscript or does Affinity make a Faux version. Is there a email address where i could send questions about using Affinity programs at our school? We could be interested on installing Affinity suite on our Schools computers.
  17. How do I access the extended character set in some of the newer Opentype fonts that have alternate swash caps, etc.? Illustrator has a glyphs panel, which I don't think AD has yet, but is there another way to do this, eg. keyboard shortcut or another utility? Thanks.
  18. There are some very odd behaviours with the numerals. If I select all the text and choose Oldstyle proportional numerals, some of the numerals are lining. If I make one of the numerals tabular, all the numerals are Oldstyle. I have tried this with several fonts.
  • 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.