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

Search the Community

Showing results for 'variable fonts'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • 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.4 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

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Location


Interests


Member Title

  1. Regarding the problem of embedding variable fonts in a PDF document, you will have to bear in mind that the PDF format currently does not support OpenType variable fonts natively. That is to say, when you export a document to PDF, a standard non-variable OpenType font representing the particular predefined or custom instance you applied to your text has to be created and embedded in the PDF file. And it is the application that is responsible for creating the non-variable font to be embedded. So while an application may understand how to display variable fonts on screen, at least its predefined instances, it may nonetheless fail in PDF export, depending on whether a suitable conversion algorithm is present in the PDF exporter. For more information regarding workflow-related questions, have a look at this Indesign-related explanation by Dov Isaacs. 😀
  2. @LibreTraining, @walt.farrell Thanks for clarifying. I didn't know the GF fonts offered a choice between installing static and variable fonts. I don't recall being given a choice as to which to install, but I wasn't looking for one either. At any rate, I can reinstall the fonts as static and have them work in AD.
  3. If the only thing people are adjusting is the font weight and possibly slant, then their primary advantage is in the web domain: if your site calls for a specific font to be downloaded, without this feature, you download a light version of the font, a normal-weight version of the font, a bold version of the font, an italic version of the font... that chews up bandwidth and thus slows down the page load time, plus can be a problem for people on metered connections (where they might pay by the byte). With a variable font, you download one font and have all of them, so it can reduce page load times (resulting in a faster site) and reduce the burden on those with limited download capacity. For print, it can save disk space, but beyond that it allows for finer control of the parameters it offers. However, the technology can allow the fonts to be customized in ways other than just weight and slant if the font is designed to allow for it. The problem right now is that there are few apps taking them seriously enough for the font vendors to put much effort into offering other parameters that could have provided a much more rich set of ways to customize the shape of the fonts. Currently the focus seems to be on weight and slant - but more would be possible if the technology were actually being taken seriously outside of its primary benefits for the web. Here is a site with demos of a number of such fonts: https://v-fonts.com A few of the fonts offer a "width" option to create narrow/wide flavorings. At least one of them (Belarius Var) has an option to control serifs, allowing one font to morph between being a serif font and being a sans-serif font. Another (Whirly Birdie & Whirlybats) has an "Animation" parameter that you can drag back and forth to animate the characters of the font (not useful for that purpose in print, but still shows some creativity and demonstrates that there is potential to do a lot more with this technology than most people currently seem to realize). There are one or two others with some creative parameters as well.
  4. I already got them from above, and could convert them, but they are rather limited even after conversion. You may want to try a free open source alternative - Bodoni from indestructible type. The GitHub version has 7 optical sizes, 4 weights, with italics, small caps, tabular figures, oldstyle figures, stylistic sets, and other OpenType features - and about double the number of characters. Download the v2.3 release here: https://github.com/indestructible-type/Bodoni That ZIP includes OTF, TTF, and variable versions. Only install one of the static versions (TTF or OTF) for Affinity apps. Demo page here: https://indestructibletype.com/Bodoni.html Google Fonts has a different version of the same fonts. Bodoni Moda - https://fonts.google.com/specimen/Bodoni+Moda If those do not meet your needs, I can send you the conversions later.
  5. ..but there are still those 90% who had to wait very long for e.g. HW-acceleration.. which still often causes issues ... or are still waiting for support of variable fonts.. etc.
  6. I was questioning its use because a variable font I tried did not export well to PDF, I thought this was a common problem with variable fonts and PDFs for print at the moment. After trying a different variable font I did not have the issue so I think it was isolated. If the fonts work and export fine for pdf and print then I think they are an amazing upgrade to how we use fonts.
  7. Hello @rhavin and welcome to the forums. This is a variable font. Variable fonts are not yet supported by Affinity programs.
  8. No, Mike. These are surely not acceptable. 😀 Variable fonts generally make use of overlapping contours because it helps the interpolation. In a variable font, you will usually create an overlap when a diagonal (or curve) is intersected by a stem (for instance, the crossbar of the A in your example), such that you will get a smooth interpolation of the diagonal (curve). In non-variable fonts, overlaps are generally removed in the font production process, not least for the reason that fonts with overlapping glyphs will generally require to store a larger number of nodes in the font file. But of course, when you have overlapping contours in a font, the rasterizer has to use the correct fill algorithm. Instead of an even-odd-fill algorithm, a non-zero-fill algorithm has to be used. Otherwise you’ll get a void like in your example. That void indicates that the rasterizer does not parse the font correctly, for one reason or another. I haven’t checked the Quicksand fonts in that respect. But to give another example, Apple recently decided to ship their system font (SF Pro) as a variable font (see below). When you load this font in Affinity Designer, the predefined instances (styles) can all be used and are rendered correctly. Now, when you convert the uppercase A of this font to curves, you’ll see again that it has overlaps. So Affinity Designer correctly uses the non-zero-fill rule to display the glyph in the running text, but when you convert to curves and switch to the even-odd-fill algorithm, you’ll get the same picture as in your example.
  9. The Github project seems to prepare Quicksand as a variable font. It contains static fonts that obviously serve as masters for the production of the variable font as well as a first version of the variable font with a weight axis. In variable fonts, overlaps and loops as we can see them in the Github repository are allowed. This might be the reason why the static fonts are set up as they are. The solution is what Sean and markw already suggested, namely to use the version from Google Fonts.
  10. No, the font is technically correct. Various rendering engines, especially those that do not support variable fonts, can render each component with artifacts, including the artifacts shown in this thread. Many Google fonts on the GF website do have various issues in many applications.
  11. Yes, ID supports variable fonts. But I don't know whether Adobe has added support yet for other than the predefined weights in the variable fonts yet. Pdf generation takes more time, especially when an application can make use of user defined axis controls. Variable font support hasn't been added to the pdf spec as released. So variable fonts cannot be edited in a pdf, for instance.
  12. Hi AndreasFurster, The attached AI file is using a Variable font which is not currently supported in Affinity which I believe is why its failing to import/show up. I will get it passed over to development to see if it can be improved on import when using Variable Fonts. The Ghostscript converted PDF is also using a Variable Font, so is likely why that is not displaying correctly when switching fonts. I did switch the font to a non variable in AI and the file was then able to be imported ok!
  13. Welcome to the Serif Affinity forums, @Its_Jack. That probably indicates you're using a variable font. The Affinity applications do not support variable fonts yet. You probably need to uninstall it, and pick the standard version of the font from the "static" folder instead.
  14. Tuffy Bold (Google fonts) is close for the same characters. Bahnschrift (Regular), which ships with current Windows versions. It is a variable font and likely isn't super useful in Serif applications. DIN Medium
  15. At this point I'm starting to think they're holding back important features like variable fonts and webp support to put into a 2.0 release we have to pay to upgrade to.
  16. The default master in Mulish is ExtraLight. And when variable fonts are not supported the fallback font is the default master. So he definitely installed the variable font.
  17. You’ve actually been tricked by Google. In order to better sell your personal data, this search engine first shows you what matches your interests, then those of other searchers on the data server you depend on. This is the same principle that makes social network users believe that their very marginal opinion is in the majority. Everyone has understood that you do not use variable fonts or Opentype collections. Their main advantage is, of course, to reduce the total weight of a font family and this makes them adopted since their creation in 2016 by the Internet world. In DTP, it’s been slower, because we often only use a few different fonts in a document, and DTP software has been a little slow to implement them unlike Internet software. In the last couple of years, there has been a growing interest in DTP in this new technique, because many agencies are doing both print and screen, and also because with these fonts, most of the restrictions of DTP are minimized. In addition, many forges often offer only these formats, which further speeds up the process…
  18. @walt.farrell It turns out GF does have the current axis registry listed in a user friendly way. It is at the bottom of their variable fonts list - there is an Axis definitions tab. https://fonts.google.com/variablefonts#axis-definitions Those are just brief descriptions. The GF Knowledge info in-progress will expand on that with demo images, etc.
  19. @walt.farrell Because nothing has happened regarding this in the "official" repo, Google Fonts established their own Axis Registry for their own use (and their web font API) and to provide some clarity to the entire variable font ecosystem. https://github.com/googlefonts/axisregistry It currently has 23 axes accepted into this registry. https://github.com/googlefonts/axisregistry/tree/main/Lib/axisregistry/data And there are many more axes proposed in the issues tracker: https://github.com/googlefonts/axisregistry/issues And there a few other proposals scattered around the GF repo. They do not treat this as "this is our way" but more of a place to get ideas, and feed back, and then to propose clear definitions of each axis to help everyone going forward. For example every one needs to be on the same page in defining the Italic axis vs. the Slant axis. So users will know what to expect when they encounter a font with these. There is also guidance on the "best" scale(s) to use the various axes, and why. I know this registry is not very helpful regarding clarity for the end user right now. But GF is currently working on an update to their GF Knowledge pages which will provide good descriptions of every axis - which will be very helpful for all end users. I see their updates and discussions almost every day as they work on this. You can see some examples of that here (they call it GFK): https://github.com/google/fonts/search?q=GFK&type=issues I am not sure of the timeline for publishing that, but they are diligently working on it. Since it is CC licensed we will be able to share it in different forms.
  20. I want to use fonts downloaded from google fonts, and they download as a variable font ttf. So, without this feature, I'm restricted in design options. They do correctly load in kind of, in so far as the list of weights is the same length as the weights in the family, but one weight takes place for every single one. I'd consider this a bug. I see the topic goes back two years. In absence of the feature, can anybody recommend solutions to extract the individual weights from the ttf as a workaround?
  21. @walt.farrell don't forget that they are still very useful for folks exporting to bitmap and vector (via curve outlines) formats, providing them with additional flexibility to customize and tweak their text elements using the various axis provided. This is especially useful as doing significant vector manipulation of outlined fonts in Designer is not exactly a pleasant experience currently, and having to redo that work should the text change makes me weep. The importance of being able to retain those text elements as editable text shouldn't be overlooked just because the output is rendered static (without variable fonts).
  22. Since you had a previous version of Office installed, with fonts included, and now you have M365 in which Calibri is probably now a cloud font, I wonder if you have some sort of font cache issue. On Windows if you have a font actually installed it will not download the cloud font. For example to get it to download the static cloud versions of Bahnscrift, I had to delete the Bahnschrift variable font (which is protected). I would check to see if Calibri is in the CloudFonts cache folder. And I would check to see if Calibri is still installed in your normal fonts folder. APub can see the font like it is a normally installed font, so I assume it is there. If it was only a Cloud font, only Office apps could see it (like Word). I cannot check all this - we need some other Mac users with Office and Calibri. Ugh, cloud fonts, wadda nightmare.
  23. Been sitting here looking at all these tools and thinking about this. There are another 4-5 online tools which also support variable fonts. Most of these tools really need a User Guide to get the most out of them. To do that properly would take quite awhile. A good idea, but time consuming. Think I will just do an Online Font Tools post - a kind of summary of all the tools. That would get people the web links and a good tool summary fairly quickly. Gawd I hate doing half-a$$ed docs; it is painful. Really needs lots of pics. But I guess it is good to get the info out there in some form sooner, rather than later.
  24. Thank you very much for pointing to PDF format and for the link. So to avoid using variable fonts with APub or InDesign or whatever, it would be helpful to KNOW which fonts are variable and which ones are not. To be quite honest I haven't thought about this separation of fonts up to now. As Dov Isaacs writes it could take years until the PDF specification takes care of variable fonts. So there is no other way than avoiding these fonts, isn't there?
  25. You're welcome. I am not sure what you mean by "picture in picture", but here is a clip showing what I mean by duplicating placed pages and cropping them so that parts that need to be updated are clipped out. In this case the year 2021 is updated to 2022 by using an existing "2" from a copy of the page, but basically fixes would need to be made by using installed fonts (or their close "relatives"). The idea, however, is to show that by using "Passthrough" you can reproduce (re-export) a production PDF without touching the original, which in this case was created in QuarkXPress 2018, using legacy Type 1 font [not basically "supported" anymore by the high and mighty] and having itself placed PDFs created in InDesign (Arabic text) and VectorStyler (variable font and warped text, which were vectorized already when initially creating the exported PDF by VectorStyler). The production PDF that was used in Publisher was created in PDF/X-1a:2001 (not reproducible by PDFLib that Affinity apps are depending on when producing PDFs), which needs to be exported using "PDF (press-ready)" to avoid rasterizations. The clip shows that nothing is rasterized, and parts that were initially fonts, are fonts still when exported from Publisher, and that all colors, including spot colors, are passed through. Attached are the source PDF, Publisher document, and fixed PDF. As mentioned, an easy alternative would be using a professional PDF editor like Adobe Acrobat Pro [still purchasable based on "perpetual" license model whatever that means especially on macOS platform] or PDF/X-Change, and directly change the year "2021" to "2022", and just save. PDF Expert (the macOS editor I purchased) could not do it, because it would not keep the spot color (and would not keep even a CMYK color). It would still be a useful tool when replacing, inserting or deleting single pages, arranging pages, or merging PDF files, disregarding the color space, and doing annotations and text editing RGB files.
×
×
  • 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.