Jump to content

Floor

Members
  • Posts

    43
  • Joined

  • Last visited

Everything posted by Floor

  1. @dcarvalho84 Thanks for the kind words and helping with support 😆 much appreciated! @deepblue If you have any questions about Typeface app just let me know. But let's not get off-topic too much here, the original post is about fonts on Windows
  2. Ahh thanks for the info! Wasn't aware of the different default gamma values, unexpected but interesting. Cheers!
  3. Not sure if I'm doing something wrong here, but it looks like text color is rendered incorrectly when setting opacity < 100% on a text layer. Opacity seems to be calculated correctly when making a parent group transparent. Attached a simple test case: no background - layers 50% opacity - ok no background - group 50% opacity - ok white background - layers 50% opacity - incorrect? white background - group 50% opacity - ok All fill colors are set to black so I expect 50% opacity to become rgb(128,128,128). However the color of the text becomes rgb(161,161,161) when using 50% opacity. Affinity Designer 2.5.3 - macOS Sonoma 14.5 text-opacity.afdesign
  4. Not sure if this is tracked, but just FYI: the issue is still present in RC1 2.5.0.2463
  5. Both XOPQ and CTST axes are not hidden in the trial font Pappardelle-VF.ttf
  6. SF Pro from Apple is a variable font with a hidden Width (wdth) axis. https://developer.apple.com/fonts/ It shows up correctly in 2.5.0 (2449) (macOS) and enabling 'Show Hidden Axes' reveals the Width axis.
  7. Who's they? Adobe? I honestly don't know the ins and outs of the spec, but as far as I understand nameID 25 is optional. A type designer can also add a custom PostScript name to each variable instance in fvar. Then nameID 25 isn't used (for those named instances). This is the most straightforward in my opinion, you can directly identify a named instance by its custom PostScript name. Adobe has a spec that defines how a PostScript name should be constructed if there is no custom one (and for custom axes values), but all this doesn't (shouldn't?) really matter for Affinity. I have no knowledge of the internals of Affinity, but this is how I expect it to work: Affinity loads available fonts on launch. This list is given by macOS. Each font in the list has a PostScript name, as provided by macOS. When a user uses a font its PostScript name is written to the document. When the document is reopened Affinity asks macOS for the font with the saved PostScript name. Variable axes don't matter, because those are applied on top of the loaded font. Affinity doesn't have to construct any PostScript names in this case. InDesign might store the constructed PostScript name in their document. Such that it can identify the exact var axes, for example: RobotoFlex_20.000slnt_372.000wght.
  8. Fonts may define their own display name for variable axes. They're included in the Name table. But the list from Google should be a good general fallback. Note that only lowercase axis ids are official according to the spec. The uppercase ids are vendor specific, so in theory a particular axis could have a different name/meaning depending on the font.
  9. I believe InDesign uses custom font loading. Fonts are typically identified by their PostScript name. It doesn't really matter how to identify a particular instance of a variable font, as the variable axes are applied after loading the font file.
  10. I'm the developer of Typeface app — a font manager for macOS The app listens for font requests using macOS APIs. Static font requests and variable named instances come through, but when an axis is changed there is no request.
  11. It could be related, but I would indeed expect a font request for the changed font name. Instead no request is received at all.
  12. Affinity Designer/Publisher/Photo Beta 2.5.0 (2415) When opening a document which uses fonts Affinity Designer tries to load the fonts to display them. The fonts may be missing (deactivated), in that case macOS implicitly sends a font request to external applications, such that font managers can automatically provide the missing fonts if they're available. This works correctly for static fonts and variable fonts that use one of the named presets. For example when using the variable RobotoFlex-Regular in a document (without changing any variable parameters) Affinity will correctly request RobotoFlex-Regular on reopen. If any of the parameters of a variable font is changed, such that it doesn't match with any of the named instances, then the Affinity apps do not send a font request. This means that font managers do not have the opportunity to auto activate the missing variable fonts. For example: Activate variable Roboto Flex in a font manager Open a blank document in Affinity Designer 2.5.0 Add a text block and use Roboto Flex Adjust the weight axis to 415 (this doesn't match with any named instance) Save and close the document Deactivate the variable Roboto Flex in a font manager Reopen the document => Font is missing (expected), but also no font request is sent so the font cannot be auto activated by macOS It's a bit hard to verify/reproduce this, as the font request happens behind the scenes in macOS and you need a font manager to capture this request. Font requests are typically sent automatically when a font is loaded using an NSFontDescriptor. For example loading a font using a descriptor with a font name NSFontDescriptor(fontAttributes: [ .name: "RobotoFlex-Regular" ]) will look for any available font with that name. It seems like Affinity loads a font differently when axes are adjusted. (Note that this only applies to missing, deactivated fonts. Activated fonts are correctly loaded on document reopen.) If any additional information is needed I'm happy to help.
  13. Those axes are marked as hidden in Roboto Flex. According to the spec: "If this flag is set, the axis should not be exposed to users in application user interfaces except in specialized scenarios, such as a font inspection utility." Although it's a bit strange that Google does show all axes on their own type tester page: https://fonts.google.com/specimen/Roboto+Flex/tester?query=roboto+flex edit: see above posts
  14. Fix confirmed on Beta 2.4.2-2356 — thanks!
  15. I'm a macOS developer working on integration with Affinity apps using drag and drop. When using the macOS NSFilePromiseProvider api to drag a promised file to a document in any of the Affinity apps they'll crash immediately on drop. It seems like Affinity v2 doesn't handle promised files correctly. See attachment for sample crash report. The issue can be reproduced consistently by dragging from any app that offers file promises without also providing a direct url using `public.file-url`. Examples: Contacts 1. Open a document in Affinity Designer 2. Open macOS Contacts app 3. Drag a contact to the open document => crash ForkLift - https://binarynights.com 1. Connect to a remote location 2. Drag a file from remote to open Affinity document => crash Typeface app - https://typefaceapp.com 1. Drag a font to an open Affinity document => crash Sample Code Project for NSFileProvider See https://developer.apple.com/documentation/appkit/documents_data_and_pasteboard/supporting_drag_and_drop_through_file_promises 1. Build and run 2. Drag image to window 3. Drag image from window to open Affinity document => crash Drag and drop from macOS Photos app works fine, because in addition to a file promise it also offers a url to a file on disk (`public.file-url`) and its contents (`public.jpeg`). That seems to work, but is not possible for apps that deal with data that does not exist locally yet. For my specific use case (Typeface app) it would be great if a file promise of type `public.directory` could be rejected by the Affinity apps, because dropping folders is not supported anyway. This could for example be done by refusing the drop when implementing NSDraggingDestination Possibly related to `af-1162` ? Affinity Designer/Photo/Publisher 2.4.0 macOS Sonoma 14.3 crash.txt
  16. Can confirm, copying text when the system language is set to Japanese sets the following invalid rtf data to the clipboard: public.rtf {¥rtf1¥ansi¥ansicpg1252 {¥fonttbl {¥f0 ArialMT;}} {¥colortbl;¥red0¥green0¥blue0;¥red255¥green255¥blue255;} ¥pard¥plain¥fs229 Test¥fs0¥lang1024} Instead of the proper rtf syntax: {\rtf1\ansi\ansicpg1252 ...
  17. What macOS version are you using? I believe that since macOS 13 Ventura the list is significantly smaller and not *all* Noto fonts should be visible. It's similar to the last screenshot—just 5 Noto fonts. If you're using an older macOS version you may be able to hide some of the (supplemental) Noto fonts using a third party font manager. That is not possible anymore on Ventura and later, but in that case the font list is smaller by default.
  18. This might already be included in this report/fix, but just to be sure: when pressing Command and clicking on a text layer (Move Tool activated), the second click will change to the Text Tool. That makes the selecting workflow a bit cumbersome, because I have to change back to the Move Tool each time. Activate Move Tool Cmd-click on text layer A (-> layer A selected) Cmd-click on another text layer B (-> layer B selected + Text Tool activated + curser inside text) I'd like to keep the Move Tool active, in order to select/move another layer. Now I have to press Escape to get out of the text field and press V to switch to the Move Tool again. I'd expect a double click on a text layer to activate the Text Tool, but a single click (with or without Command) should only select the layer. (The Option-click workaround only works if the text layers are all in the same group. If they're not in the same group Option-click will select a group instead of a single layer.)
  19. You can indeed 'use' variable fonts (the named instances) in Affinity apps, but they're not 'supported'. What this means is the following: Affinity can load variable fonts: YES Affinity can use variable font named instances (regular/bold etc.): YES Affinity can adjust variable axes: NO Affinity can render variable font named instances correctly: NO The biggest issue is point 4: while you can choose a named instance of a variable font, it doesn't render correctly. See screenshot: left is Affinity, right is another app that renders variable fonts correctly. As you can see the tracking/kerning is incorrectly using the Regular values, instead of the values for the named instances. Font used: SF Pro variable. The ability to adjust and tweak variable axes (point 3) would also be great, but rendering named instances correctly would already be a great improvement.
  20. I'm very excited about scripting support, can't wait to play with it! The previews look promising. If there is one thing I could request it would be the ability to run/trigger a script from outside of the Affinity app UI. For example I'm the developer of a font manager app for Mac, and it would be great to be able to adjust fonts and text properties from within the external app. Currently using the macOS Accessibility api to do something similar, but with scripting it can be made much more user friendly. Sketch includes a `sketchtool` binary that can run any plugin and pass some context (for example json). It's fine if the user would need to explicitly 'install' a plugin for security, but it would be nice if such a plugin/script can be triggered without any further user interaction. Another option would be an Apple Script handler that can kickstart a plugin/script and pass context, but that's not cross platform of course.
  21. Thanks @Dan C for looking into it, much appreciated! I can confirm this as well. I can reproduce the issue on Intel (Ventura + retina screen, Monterey + non-retina screen) and on M2 (Ventura + retina screen), using the same sample document. So I don't think it's limited to M1/M2 devices.
  22. Ah apologies if this has already been reported before, I couldn't find similar posts when searching in this AD2 topic. It's indeed interesting that it's inconsistent, looks like some kind of caching issue. And it does also happen at 100% zoom if an inserted image itself is scaled to 200%. Weird!
  23. Thanks for your reply! The document is included in the original post, see 'pixel-square.afdesign' I'm aware of pixel-alignment of artboards and objects, which can be annoying as well for UI work. But it's not what I try to demonstrate in this report Main use case is UI work, so I don't care about physical measurements or print size. The only thing I care about is that the pixels I create are mapped to exact (multiple of) screen pixels. The document uses 100x100 pixels — which is 50x50 screen points on a retina screen. That's too small, so I zoom to 200% to get the correct size. See attached screen recording for details — I pinch then press Command-2 to go to 200% zoom. This is on a Retina display, but the same happens on a non-retina display. Artboard1 = original rectangle objects Artboard2 = 100x100 png of Artboard1 Artboard3 = 200x200 png of Artboard2 (scaled 50%) Screen Recording 2023-03-24 at 13.47.33.mov
  24. Thanks for the details! I'll take a look at mipmaps. I assume mipmaps are deterministic? If they are, why does this issue happen occasionally, after repeatedly zooming and switching to 200%. It's not *always* blurry at 200% zoom. To reproduce: pinch to zoom, then press Command-2 to switch to 200%. About 50% of the time the image is blurry on screen. At 100% zoom everything is pixel perfect for this particular document. The main reason I'm using 200% zoom is because this is a non-Retina document that I'm viewing on a Retina display. In order to get the projected size the same as on a non-retina screen I need to zoom to 200%. Alternatively I can make the document 144dpi and use points instead of pixels. In that case 100% zoom on a Retina display will show the correct projected size. The document will have more underlying pixels, that's all fine. Now if I insert a non-retina 72dpi image into that 144dpi document, I'll have to scale that img up to 200% to get the correct projected size. In this case the exact same issue pops up at 100% zoom. See attached document. This is the same doc as before, but it's 144dpi and the image in Artboard 2 has been scaled up by 200%. pixel-square-r.afdesign
×
×
  • 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.