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

Variable Font Support Discussion (split)


Recommended Posts

<mod edit>

The replies below were made in relation to a post pre announcing Variable Font Support

On 4/12/2024 at 1:53 PM, Ash said:

We are adding variable support to 2.5 but is still going through some final internal testing. This should be available in a beta update next week.

</mod edit>

An important step, but don't discount that color font support is also important.

If not in parallel to variable fonts, please make sure these are not neglected either!

Link to comment
Share on other sites

@Ash What is the plan since PDFs and SVGs don't support these?

Lenovo IdeaPad 5 Ryzen 7 5700U Rx Vega 8 graphics 

16GB RAM (15.3 usable) 

Acer KB202 27in 1080p monitor

Affinity Photo 1.10.6

Affinity photo 2 2.4.2 Affinity Designer 2 2.4.2 Affinity Publisher 2 2.4.2 on Windows 11 Pro version 23H2

Beta builds as they come out.

canon 80d| sigma 18-200mm F3.5-6.3 DC MACRO OS HSM | Tamron SP AF 28-75mm f/2.8 XR Di LD | Canon EF-S 10-18mm f/4.5-5.6 IS STM Autofocus APS-C Lens, Black

 

Link to comment
Share on other sites

3 minutes ago, tzvi20 said:

What is the plan since PDFs and SVGs don't support these?

For PDF, presumably the same as every other application that supports Variable fonts and PDF: the application must generate a Static subset of the Variable Font and embed that in the PDF. Or it must Convert to Curves.

I have no idea about SVG, except perhaps using Converting to Curves.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.5, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.5

Link to comment
Share on other sites

20 minutes ago, walt.farrell said:

For PDF, presumably the same as every other application that supports Variable fonts and PDF: the application must generate a Static subset of the Variable Font and embed that in the PDF. Or it must Convert to Curves.

I have no idea about SVG, except perhaps using Converting to Curves.

For SVG you can use variable fonts if the rendering application supports it. ie: you can use variable fonts in most web-browsers available today. For other contexts such as importing into other applications; CAD, 3D tools, cutting tools, etc I suspect most SVG implementations in these contexts won't support variable fonts and converting text to curves will likely produce much better results.

Link to comment
Share on other sites

@Ash, it’s great to see support added for this format of fonts. Will this new font support upgrade also feature support for single stroke /centerline fonts used in CNC applications? Single stroke fonts do not define glyphs using a perimeter outline filled with color, but by a single path (just like handwriting) to define the centerline of the letterform, with no outlines around the glyph.

PLEASE PLEASE PLEASE PLEASE include support for this font format. It dovetails perfectly with the new DXF support. I can’t use ANY affinity apps for typography bc support for single stroke fonts is missing….

2021 16” Macbook Pro w/ M1 Max 10c cpu /24c gpu, 32 GB RAM, 1TB SSD, Sonoma 14.4.1

2018 11" iPad Pro w/ A12X cpu/gpu, 256 GB, iPadOS 17

Link to comment
Share on other sites

  • Staff
16 minutes ago, tzvi20 said:

What is the plan since PDFs and SVGs don't support these?

Actually currently for SVG we will always convert a variable font to curves.

For PDF as Walt suggests we effectively create a new static font with the attributes applied which we embed within the PDF file. i.e. if you use 5 variations of the same variable font within your document, the PDF will have 5 'different' static fonts embedded.

Managing Director

Help make our apps better by joining our beta program!


MacBook Pro (16-inch, 2021) / Apple M1 Max / 64GB / macOS 12.0.1

iPad Pro 11-inch 3rd Gen / iPadOS 16.2

Link to comment
Share on other sites

  • Staff
5 minutes ago, ronnyb said:

PLEASE PLEASE PLEASE PLEASE include support for this font format. It dovetails perfectly with the new DXF support. I can’t use ANY affinity apps for typography bc support for single stroke fonts is missing….

Thanks Ronny - agree and will get on list, but it is another body of work so can't say when that will come.

Managing Director

Help make our apps better by joining our beta program!


MacBook Pro (16-inch, 2021) / Apple M1 Max / 64GB / macOS 12.0.1

iPad Pro 11-inch 3rd Gen / iPadOS 16.2

Link to comment
Share on other sites

8 minutes ago, Ash said:

Thanks Ronny - agree and will get on list, but it is another body of work so can't say when that will come.

Thanks for replying @Ash Btw there is currently partial support for single stroke fonts, except some characters don’t render, so hopefully it wouldn’t be a huge deal for the devs to slip it into an upcoming beta…

2021 16” Macbook Pro w/ M1 Max 10c cpu /24c gpu, 32 GB RAM, 1TB SSD, Sonoma 14.4.1

2018 11" iPad Pro w/ A12X cpu/gpu, 256 GB, iPadOS 17

Link to comment
Share on other sites

9 minutes ago, Ash said:

Thanks Ronny - agree and will get on list, but it is another body of work so can't say when that will come.

Accordingly, shouldn't that be in the Feedback forum as it is not for this beta?

In any case, since these fonts are constructed by center-line strokes, when this is done, please consider leveraging that fact by allowing brushes to be applied to them (for those not doing CNC work, anyway...).

Link to comment
Share on other sites

Variable fonts are a useful addition also with regard to use in web designs.

But there is something strange i found when using the "new" Roboto Condensed from fonts.google.com. I guess this is not a bug, it also appears in the current v2.4.2.

https://fonts.google.com/specimen/Roboto+Condensed

For compatibility reasons with current web projects i installed the 18 "static" font styles, not the single variable font itself (RobotoCondensed-VariableFont_wght.ttf).

image.png.571efb06cc657ff53af637b925832dfd.png

Here is the test file:

2024-04-19-variable-fonts-roboto-artefacts_1-1.afpub

As soon as a drop shadow or other effects are applied to the text frame, visible artifacts occur depending on the letter.

image.png.ce2857ddc2a158ba6f8e36e5faeb52bd.png

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. Your can see this in the wireframe view even without converting the text frame to pathes.

image.thumb.png.ea962e5b2d489ec1027005e9cca21e48.png

The problem now seems to be that for certain letters, especially the bottom and top edges, the effects are applied to the internal individual shapes instead of to the entire letter (composite shape). Depending on the font size, this results in “bumpy” outlines.

This doesn't just seem to be a display problem in the editor only. Some of the artifacts are retained even when exporting for the web (PNG, JPEG).

Did the developers also experience such artifacts during the integration of the real variable fonts? Or is this a special case that occurs when a variable font is broken down into individual font styles ("static") for compatibility reasons. Like Google did with the Roboto Condensed variable font.

Hardware: Windows 11 Pro (23H2, build 22631.3880, Windows Feature Experience Pack 1000.22700.1020.0), Intel(R) Core(TM) i9-14900K @3.20 GHz, 64 GB RAM, NVIDIA RTX A4000 (16GB VRAM, driver 551.61), 1TB + 2TB SSD. 1 Display set to native 2560 x 1440.
Software: Affinity v1 - Designer/Publisher/Photo (1.10.6.1665), Affinity v2 (universal license) - Designer/Publisher/Photo, v2 betas.

Link to comment
Share on other sites

1 hour ago, 4dimage said:

Variable fonts are a useful addition also with regard to use in web designs.

But there is something strange i found when using the "new" Roboto Condensed from fonts.google.com. I guess this is not a bug, it also appears in the current v2.4.2.

https://fonts.google.com/specimen/Roboto+Condensed

For compatibility reasons with current web projects i installed the 18 "static" font styles, not the single variable font itself (RobotoCondensed-VariableFont_wght.ttf).

image.png.571efb06cc657ff53af637b925832dfd.png

Here is the test file:

2024-04-19-variable-fonts-roboto-artefacts_1-1.afpub

As soon as a drop shadow or other effects are applied to the text frame, visible artifacts occur depending on the letter.

image.png.ce2857ddc2a158ba6f8e36e5faeb52bd.png

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. Your can see this in the wireframe view even without converting the text frame to pathes.

image.thumb.png.ea962e5b2d489ec1027005e9cca21e48.png

The problem now seems to be that for certain letters, especially the bottom and top edges, the effects are applied to the internal individual shapes instead of to the entire letter (composite shape). Depending on the font size, this results in “bumpy” outlines.

This doesn't just seem to be a display problem in the editor only. Some of the artifacts are retained even when exporting for the web (PNG, JPEG).

Did the developers also experience such artifacts during the integration of the real variable fonts? Or is this a special case that occurs when a variable font is broken down into individual font styles ("static") for compatibility reasons. Like Google did with the Roboto Condensed variable font.

If the nodes on the outlines have the same coordinates (and in digital typography, especially from quality purveyors like Google, that is usually the case, as current font formats do not support floating point coordinates and, thus, type designers have a habit of zooming in and snapping everything correctly, working with coordinate labels on nodes toggled on to be able to check them at a glance, etc.), it should actually be a bug in Affinity's rasterizer, I'm afraid.

If you don't have access to a font editor like FontLab Studio, you can always convert those into curves and check if their coordinates match. I suppose a workaround could be for you to then add all the resulting shapes into a single one, but it's still a pretty basic bug that shouldn't happen.

Link to comment
Share on other sites

4 hours ago, fde101 said:

An important step, but don't discount that color font support is also important.

If not in parallel to variable fonts, please make sure these are not neglected either!

Word. @Ash, if you want me to try and patch Sérgio Martins (former type design engineer at Adobe who worked on the colour SVG version of Carol Twombly's Trajan Pro – incidentally, Adobe's very first colour font) through, hit me up.

Both my PhD supervisor and I have worked with him as co-tutors before, so he's just a phone call away, and if anyone is well-versed in the colour OpenType-SVG font spec, that would be him. Last time I've checked, he's currently freelancing as a type design engineer and only giving the occasional lecture at Reading, so… short of poaching employees straight from Adobe, that's the next best thing. 😉

Just a heads-up: he will most likely charge fees for consultancy, but such is the cost of doing business with experts living in the über-expensive Lisbon metro area, I guess. 🙃

Link to comment
Share on other sites

1 hour ago, tzvi20 said:

@Ash Will there be a panel or dialogue box to control these? In InDesign it is in the character panel.

I would have thought a dialog box is rather too transient for something like this. I hope the controls will be added via a panel.

Alfred spacer.png
Affinity Designer/Photo/Publisher 2 for Windows • Windows 10 Home/Pro
Affinity Designer/Photo/Publisher 2 for iPad • iPadOS 17.5.1 (iPad 7th gen)

Link to comment
Share on other sites

What would be really interesting would be to also find a way to represent at least some of the common ones as handles on the letters (when zoomed in far enough!!!) the way that handles are used for rounding rectangles and shaping gears and the like...

The Typography panel would be a logical place for these otherwise, in my way of thinking.

Link to comment
Share on other sites

2 hours ago, fde101 said:

What would be really interesting would be to also find a way to represent at least some of the common ones as handles on the letters (when zoomed in far enough!!!) the way that handles are used for rounding rectangles and shaping gears and the like...

The Typography panel would be a logical place for these otherwise, in my way of thinking.

That is an extremely interesting, patent- or OpenType-spec-worthy feature. But, as you may guess, I suspect that would only happen if Serif/Canva brought that idea to the table, perhaps, again, along with another company and set of developers like those at FontLab Inc. or Glyphs GmbH.

You see, the Variable OpenType font format is a bit of free-for-all, anything goes! They are axis-based, and there aren't exactly standards set in stone. As a matter of fact, it is impossible to anticipate everything and anything type designers may come up with. LTR Beowulf by LettError and Chee by OH no Type Company should tell you all you needed to know about just how wildly creative they can be once they become proficient with this technology.

Surely we can band together and crystallise all the historical, most obvious axes (like width/weight, optical size, slant, etc., as defined in the OpenType Design-Variation Axis Tag Registry…), but if we were to stay true to Variable OT's (and, indeed, Gerrit Noordzij's and Catherine Dixon's) infinitely flexible and expandable conceptions of typography, we would have to come up with an equally and inherently flexible “standard-less standard”, which type designers themselves could use as they saw fit and make visible on various software packages' UIs.

I have been mulling over the use of private use area/OpenType-specific and non-Unicode glyphs dedicated to UI elements for axis labelling on Character/Variable Font interface panels (type design apps are, after all, vector editors par excellence, and type designers are obviously expert vector designers, which means the results would be, in general, very decent and compelling). That might mean that conceptually similar axes could have slightly different (and, in some cases and for a while, wildly different) labels across different fonts but, as with all other things, over time some new standards (mirroring what Dixon calls, in her advanced typographic categorisation/taxonomy system, “patterns”) would eventually emerge.

Could we use the same ideas and tech for, say, custom cursors? Toolbar button icons? Direct axis control nodes? Hover labels/interface aids/naming for the latter or even all of them? Could we even take all of these principles and help solve the mess that are currently the heretofore cryptically-numbered OT Stylistic Sets in one fell swoop? Maybe.

Your additional ideas regarding direct manipulation are very intriguing, and if you're willing to cooperate with our Typography research group on a future paper/patent (or, at the very least, provide me with your real name so you can be properly credited for the idea), hit me up. None of this can happen in a vacuum, and requires some degree of cross-disciplinary cooperation (scholars, type designers, and type design and DTP software developers – Serif, once again, I'm also looking squarely at you, and I suspect my exclusivity agreement doesn't preclude from working on or even receiving royalties from IP), followed by some industry-wide agreement.

Ultimately, the arbiters of any proposed extensions will be Microsoft and Adobe themselves, as they're the ones who created OpenType in the first place (I don't fully understand exactly which company actually controls it, but it seems to be Microsoft). If you want to see how things stand right now, take a gander at the OpenType 1.9.1 Alpha spec page. There's a lot of interesting stuff there, including, incidentally, a new “colr” table for colour fonts

I would also recommend that @Ash and the team keep an eye on these developments, especially if you think waiting for the final spec to be published is a sensible approach to supporting colour OpenType-SVG fonts in a future version of Affinity.

Link to comment
Share on other sites

46 minutes ago, JGD said:

if you're willing to cooperate with our Typography research group on a future paper/patent

This is almost as bad as RED getting a patent on lossy-compressed RAW encodings that happen to be above a certain resolution.  Making it specific to high resolutions suddenly gets past prior art of doing exactly the same thing at lower resolutions, which had been around since before RED existed?  Patenting a specific algorithm for doing that - maybe, but stretching it.  Patenting it as a concept?  Inexcusable.

There is plenty of software which moved (or duplicated) sliders and numeric fields onto the canvas in the form of handles, so creating on-canvas handles for yet another set of sliders is suddenly inventive enough to be patentable?  The patent offices may be stupid enough to let something like that slide, but they certainly shouldn't be.

Direct manipulation of just about anything should be an obvious end goal by now, hardly inventive enough to be considered for a patent, even if no one else has tried it yet.

Link to comment
Share on other sites

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-issues

Future 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-file

They 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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

I'm accustomed to looking for overlaps when using Variable Fonts (in either Adobe Illustrator or CorelDRAW). 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). For most users this is not a big deal. But if you're creating lettering that will be sent to a vinyl cutter or cut out of aluminum on a computer driven routing table the overlaps can be very bad. Out of habit I'm looking at every project in outline view.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

On 4/19/2024 at 6:59 PM, fde101 said:

This is almost as bad as RED getting a patent on lossy-compressed RAW encodings that happen to be above a certain resolution.  Making it specific to high resolutions suddenly gets past prior art of doing exactly the same thing at lower resolutions, which had been around since before RED existed?  Patenting a specific algorithm for doing that - maybe, but stretching it.  Patenting it as a concept?  Inexcusable.

There is plenty of software which moved (or duplicated) sliders and numeric fields onto the canvas in the form of handles, so creating on-canvas handles for yet another set of sliders is suddenly inventive enough to be patentable?  The patent offices may be stupid enough to let something like that slide, but they certainly shouldn't be.

Direct manipulation of just about anything should be an obvious end goal by now, hardly inventive enough to be considered for a patent, even if no one else has tried it yet.

I didn't say it had to be patented, now, did I? Also, I'm discussing it out on the open. I'm not a developer, I'm a type designer and a teacher.

Heck, if I knew this thing was going to make everyone's lives easier and their work more creative, and would otherwise preclude others from implementing somewhat similar ideas, I'd give it away for free. I am with you on the fact that extremely generic ideas shouldn't be patenteable, FWIW.

Link to comment
Share on other sites

On 4/19/2024 at 8:41 PM, kenmcd said:

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-issues

Future 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-file

They 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.

Thanks for the correction. I'm obviously not as well-versed in this as Sérgio.

As for them not being able to be made variable, I wasn't sure of that but half-suspected already, and I don't see why it doesn't belong in this discussion, at least as a starting point, because after variable fonts… it's the next obvious omission to tackle. I kindly invite the mods to split the relevant posts into a new thread if need be, of course.

I would also add that said fact is not guaranteed to always be the case. If both formats take off, there can certainly be ways of making Colour-SVG fonts support variable axes. As a matter of fact, that same philosophy could be applied to the format and turn colours, and maybe even texture and gradients, into editable “axes”, instead of the format relying exclusively on Stylistic Sets as it still does, and those Stylistic Sets might even work as sub-fonts instead of the system, with their own axes, instead of being just presets of sorts.

Regarding that newfangled Open Font Format spec, I like it, though I fear will face a bit of an uphill battle against OpenType. Anyhoo, I'll be watching Behdad Esfahbod's (impressive CV, by the way) stream when I get the time, but I looked at his presentation deck already (he mentioned advantages for the UFO format, which is a good thing, and clearly knows well the history of formats, including arcane stuff such as METAFONT), and the fact that all these bright people are putting their minds to these issues fills me with confidence.

I'll be sure to check out all those resources, thanks!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • 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.