Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

Felipe Sanches-2
Hi there,

These past days I've been adding an experimental UI to Inkscape for tweaking parameters in OpenType variable fonts. One major roadblock I stumbled upon is requiring me to think more carefully about some potentially deeper architectural changes. In the screenshot attached to this message you can see some text written with the Decovar variable font. The slider labeled "Testing" in the "Text & Font" dialog is wired to invoke a callback upon value-change. This callback detects the currently selected font based on the canvas text-tool cursor position, retrieves the corresponding font_instance object and invokes Freetype's FT_Set_Var_Design_Coordinates method with the updated design-space coordinates (the slider in this experiment is hardwired to adjust the weight axis of Decovar).

(I really miss a Freetype method to alter a single design-space coordinate, instead of having to pass the full array, by the way)

The way things work right now, unfortunately, leads to the glyphs not changing on-canvas because once they are loaded, they seem to be kept in a cache. As you can see in the screenshot, each glyph has a different weigth, based on the slider setting when the glyph was loaded for the first time. It seems quite obvious that I should do something to invalidate the cache upon dragging the slider. But that, on the other hand, should not alter glyphs in other places where the same variable font is being used in the same document.

Based on all that, I think that the proper implementation would involve creating individual font_instance objects for each text chunk where a variable-font is used with non-default design-space coordinates so that they can be tweaked independently. Achieving that, though, will surely involve a bit deeper fiddling with Inkscape's text internals, which is what I expect to do in my next few days of work on this.

cheers,
Felipe Sanches

PS:
I'm crossposting this to the Inkscape-devel mailing list as the rest of the development community may be interested in receiving updates on this topic. I may as well move all future updates to the Inkscape mailing list directly.

PS2: I heard that there's a GSoC student this year who's going to work on Inkscape's text implementation (fixing compliance issues to the SVG spec, I think...) It would be really great to keep in contact with him/her and the mentor to coordinate efforts.


2017-05-30 7:48 GMT-03:00 Khaled Hosny <[hidden email]>:
On Tue, May 30, 2017 at 12:35:24AM -0300, Felipe Sanches wrote:
> The relationship between pango and harfbuzz is still not very clear to me,
> as I have the impression that even pango_shape() invokes hb_shape() under
> the hood nowadays.

It will eventually call HarfBuzz on Linux, but in Windows and Mac it
will call Uniscribe and Core Text, respectively. Switching to HarfBuzz
on all platforms is kinda on Pango’s TODO list, but I don’t think anyone
is working on it currently.

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/googlefonts-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/20170530104838.GC24994%40macbook.
For more options, visit https://groups.google.com/d/optout.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Screenshot at 2017-06-02 22:27:41.png (373K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

Victor Westmann
Hi Felipe,

Thank you very much for keeping us posted.

Keep up the good work.



--Victor Westmann

2017-06-02 18:35 GMT-07:00 Felipe Sanches <[hidden email]>:
Hi there,

These past days I've been adding an experimental UI to Inkscape for tweaking parameters in OpenType variable fonts. One major roadblock I stumbled upon is requiring me to think more carefully about some potentially deeper architectural changes. In the screenshot attached to this message you can see some text written with the Decovar variable font. The slider labeled "Testing" in the "Text & Font" dialog is wired to invoke a callback upon value-change. This callback detects the currently selected font based on the canvas text-tool cursor position, retrieves the corresponding font_instance object and invokes Freetype's FT_Set_Var_Design_Coordinates method with the updated design-space coordinates (the slider in this experiment is hardwired to adjust the weight axis of Decovar).

(I really miss a Freetype method to alter a single design-space coordinate, instead of having to pass the full array, by the way)

The way things work right now, unfortunately, leads to the glyphs not changing on-canvas because once they are loaded, they seem to be kept in a cache. As you can see in the screenshot, each glyph has a different weigth, based on the slider setting when the glyph was loaded for the first time. It seems quite obvious that I should do something to invalidate the cache upon dragging the slider. But that, on the other hand, should not alter glyphs in other places where the same variable font is being used in the same document.

Based on all that, I think that the proper implementation would involve creating individual font_instance objects for each text chunk where a variable-font is used with non-default design-space coordinates so that they can be tweaked independently. Achieving that, though, will surely involve a bit deeper fiddling with Inkscape's text internals, which is what I expect to do in my next few days of work on this.

cheers,
Felipe Sanches

PS:
I'm crossposting this to the Inkscape-devel mailing list as the rest of the development community may be interested in receiving updates on this topic. I may as well move all future updates to the Inkscape mailing list directly.

PS2: I heard that there's a GSoC student this year who's going to work on Inkscape's text implementation (fixing compliance issues to the SVG spec, I think...) It would be really great to keep in contact with him/her and the mentor to coordinate efforts.


2017-05-30 7:48 GMT-03:00 Khaled Hosny <[hidden email]>:
On Tue, May 30, 2017 at 12:35:24AM -0300, Felipe Sanches wrote:
> The relationship between pango and harfbuzz is still not very clear to me,
> as I have the impression that even pango_shape() invokes hb_shape() under
> the hood nowadays.

It will eventually call HarfBuzz on Linux, but in Windows and Mac it
will call Uniscribe and Core Text, respectively. Switching to HarfBuzz
on all platforms is kinda on Pango’s TODO list, but I don’t think anyone
is working on it currently.

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/googlefonts-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/20170530104838.GC24994%40macbook.
For more options, visit https://groups.google.com/d/optout.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

Felipe Sanches-2
In reply to this post by Felipe Sanches-2
I'm writing this message addressed both to UI-designers in general as well as (to some extent) to senior Inkscape developers who may provide some more feedback on the actual code.
====

My current understanding regarding variable fonts is that any time the user tweaks parameters in a variable font, Inkscape will have to decide whether to modify those design-space coordinates on the font instance associated with the currently selected chunk of text or to instantiate a new font_instance object. Here's my rationale behind this:

If the SVG document has the same font applied to more than a single chunk of text, then we need to create a new font instance so that the edits to one chunk of text won't affect other chunks that were previously sharing the same font_instance. That would work as a lazy "un-clone" of the font resource once the differentiation is really needed. It is good (in order to avoid wasting memory) to share a font_instance for chunks of text that use the same non-variable font, or that use the default design space coordinates of a given variable font.

I think that allowing variable font design-space tweaks to individual chunks of text is desirable from the user perspective and also required from the SVG spec perspective. The SVG spec does not talk about variable fonts, but it allows individual text chunks to have their own font-family and style attributes which then apparently means allowing them to have their own variable font design space coordinates as well (If I understood it correctly). I think this is analogous to individual paths having their own individual fill/stroke styles.

It just occurred to me that this leads to a possible confusion and we probably have to make a UI design choice here. There may be occasions when the user may want to modify the design-space coordinates of a given variable font globally on the document. Do you think this is a valid concern / valid usage scenario ? In that case, a variable font instance may behave like a shared resource, analogous to a shared gradient or filter-effect. But then we would need to make this an explicit user-choice, perhaps by providing a dedicated dialog for setting up such shared font resources. Like a "palette of font instances". Does it make sense ? Also, from a codebase point of view, would you suggest a prefered way to approach this? (Thinking about how to manage these variable-font instances)


2017-06-02 22:35 GMT-03:00 Felipe Sanches <[hidden email]>:
Hi there,

These past days I've been adding an experimental UI to Inkscape for tweaking parameters in OpenType variable fonts. One major roadblock I stumbled upon is requiring me to think more carefully about some potentially deeper architectural changes. In the screenshot attached to this message you can see some text written with the Decovar variable font. The slider labeled "Testing" in the "Text & Font" dialog is wired to invoke a callback upon value-change. This callback detects the currently selected font based on the canvas text-tool cursor position, retrieves the corresponding font_instance object and invokes Freetype's FT_Set_Var_Design_Coordinates method with the updated design-space coordinates (the slider in this experiment is hardwired to adjust the weight axis of Decovar).

(I really miss a Freetype method to alter a single design-space coordinate, instead of having to pass the full array, by the way)

The way things work right now, unfortunately, leads to the glyphs not changing on-canvas because once they are loaded, they seem to be kept in a cache. As you can see in the screenshot, each glyph has a different weigth, based on the slider setting when the glyph was loaded for the first time. It seems quite obvious that I should do something to invalidate the cache upon dragging the slider. But that, on the other hand, should not alter glyphs in other places where the same variable font is being used in the same document.

Based on all that, I think that the proper implementation would involve creating individual font_instance objects for each text chunk where a variable-font is used with non-default design-space coordinates so that they can be tweaked independently. Achieving that, though, will surely involve a bit deeper fiddling with Inkscape's text internals, which is what I expect to do in my next few days of work on this.

cheers,
Felipe Sanches

PS:
I'm crossposting this to the Inkscape-devel mailing list as the rest of the development community may be interested in receiving updates on this topic. I may as well move all future updates to the Inkscape mailing list directly.

PS2: I heard that there's a GSoC student this year who's going to work on Inkscape's text implementation (fixing compliance issues to the SVG spec, I think...) It would be really great to keep in contact with him/her and the mentor to coordinate efforts.


2017-05-30 7:48 GMT-03:00 Khaled Hosny <[hidden email]>:
On Tue, May 30, 2017 at 12:35:24AM -0300, Felipe Sanches wrote:
> The relationship between pango and harfbuzz is still not very clear to me,
> as I have the impression that even pango_shape() invokes hb_shape() under
> the hood nowadays.

It will eventually call HarfBuzz on Linux, but in Windows and Mac it
will call Uniscribe and Core Text, respectively. Switching to HarfBuzz
on all platforms is kinda on Pango’s TODO list, but I don’t think anyone
is working on it currently.

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/googlefonts-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/20170530104838.GC24994%40macbook.
For more options, visit https://groups.google.com/d/optout.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

Felipe Sanches-2
Hi there!

I was expecting to get some feedback on this thread from other Inkscape developers, but still did not really get any. So I continued investigating the issue by myself. At the moment I'm mapping out where and how the font_instances are created, deleted and used throughout the code-base because any changes I make have to consider all side-effects that may surface. I did feel a bit overwhelmed at first with the complexity of the text-handling code, but I think I'm on the right track now.

To alleviate the anxiety of dealing with such a complex large-chunk of code, I got my hands dirty by refactoring a few portions of libnrtype/Layout-*.cpp files (it's like gardening: we can't keep just staring at it :-P) and I also talked to some friends. Since a few Brazilian friends shared the enthusiasm of OpenType Variable Fonts at LGM earlier this year here in Brazil, I wrote a bit about the ongoing effort at an online forum here: https://forum.fiozera.com.br/t/suporte-a-opentype-variable-fonts-no-inkscape/115 It is all in Brazilian Portuguese, sorry, so it is probably not much useful here, but it is also not much different from what I already talked about here in this email thread which is still the official place for me to provide progress updates. Also the forum thread does not cover a lot of areas of the code I've been studying. Writing at that forum was more of a way of relaxing and getting ideas to flow again. I'll probably do so again from time to time. :-)

Since Inkscape has finally migrated to git today ("upstream" repo is now at https://gitlab.com/inkscape/inkscape), I did fork it at https://gitlab.com/fsanches/inkscape and also got my user account approved with push-rights. I was an active Inkscape developer on Bazar several years ago with equivalent commit rights.

Then I tried the "Merge Requests" workflow, but then I figured that probably the Inkscape team will (at least for a while) prefer to work directly committing to the master branch, instead of opening requests for merge. I pushed to master a few of the aforementioned refactoring commits and created a "variable_fonts" branch on my local working copy where I'll resume all of the experimental OpenType coding (to avoid polluting master before the feature is ready to land).

So, next week I plan to get back to contributing to FontBakery ( https://github.com/googlefonts/fontbakery/ ) and gradually work a bit more on Inkscape as well. Exactly which of both tasks will take most of my time will depend on the availability of Lasse's upcoming FontBakery pull request and also on the level of feedback that I may (or may not) get from Inkscape developers. I guess perhaps no-one else who originally dealt with the text-handling code in Inkscape is active in the team nowadays ? If that's the case, then I'll have to really "take ownership" of that portion of code and improve it based on my best judgement of what would be the best approaches.

One final thing: I'm really interested in talking to whoever is planning to work on a text feature on Google Summer of Code this year. Who's the student ?! Please contact me.

Happy Hacking,
Felipe "Juca" Sanches

2017-06-05 17:57 GMT-03:00 Felipe Sanches <[hidden email]>:
I'm writing this message addressed both to UI-designers in general as well as (to some extent) to senior Inkscape developers who may provide some more feedback on the actual code.
====

My current understanding regarding variable fonts is that any time the user tweaks parameters in a variable font, Inkscape will have to decide whether to modify those design-space coordinates on the font instance associated with the currently selected chunk of text or to instantiate a new font_instance object. Here's my rationale behind this:

If the SVG document has the same font applied to more than a single chunk of text, then we need to create a new font instance so that the edits to one chunk of text won't affect other chunks that were previously sharing the same font_instance. That would work as a lazy "un-clone" of the font resource once the differentiation is really needed. It is good (in order to avoid wasting memory) to share a font_instance for chunks of text that use the same non-variable font, or that use the default design space coordinates of a given variable font.

I think that allowing variable font design-space tweaks to individual chunks of text is desirable from the user perspective and also required from the SVG spec perspective. The SVG spec does not talk about variable fonts, but it allows individual text chunks to have their own font-family and style attributes which then apparently means allowing them to have their own variable font design space coordinates as well (If I understood it correctly). I think this is analogous to individual paths having their own individual fill/stroke styles.

It just occurred to me that this leads to a possible confusion and we probably have to make a UI design choice here. There may be occasions when the user may want to modify the design-space coordinates of a given variable font globally on the document. Do you think this is a valid concern / valid usage scenario ? In that case, a variable font instance may behave like a shared resource, analogous to a shared gradient or filter-effect. But then we would need to make this an explicit user-choice, perhaps by providing a dedicated dialog for setting up such shared font resources. Like a "palette of font instances". Does it make sense ? Also, from a codebase point of view, would you suggest a prefered way to approach this? (Thinking about how to manage these variable-font instances)


2017-06-02 22:35 GMT-03:00 Felipe Sanches <[hidden email]>:
Hi there,

These past days I've been adding an experimental UI to Inkscape for tweaking parameters in OpenType variable fonts. One major roadblock I stumbled upon is requiring me to think more carefully about some potentially deeper architectural changes. In the screenshot attached to this message you can see some text written with the Decovar variable font. The slider labeled "Testing" in the "Text & Font" dialog is wired to invoke a callback upon value-change. This callback detects the currently selected font based on the canvas text-tool cursor position, retrieves the corresponding font_instance object and invokes Freetype's FT_Set_Var_Design_Coordinates method with the updated design-space coordinates (the slider in this experiment is hardwired to adjust the weight axis of Decovar).

(I really miss a Freetype method to alter a single design-space coordinate, instead of having to pass the full array, by the way)

The way things work right now, unfortunately, leads to the glyphs not changing on-canvas because once they are loaded, they seem to be kept in a cache. As you can see in the screenshot, each glyph has a different weigth, based on the slider setting when the glyph was loaded for the first time. It seems quite obvious that I should do something to invalidate the cache upon dragging the slider. But that, on the other hand, should not alter glyphs in other places where the same variable font is being used in the same document.

Based on all that, I think that the proper implementation would involve creating individual font_instance objects for each text chunk where a variable-font is used with non-default design-space coordinates so that they can be tweaked independently. Achieving that, though, will surely involve a bit deeper fiddling with Inkscape's text internals, which is what I expect to do in my next few days of work on this.

cheers,
Felipe Sanches

PS:
I'm crossposting this to the Inkscape-devel mailing list as the rest of the development community may be interested in receiving updates on this topic. I may as well move all future updates to the Inkscape mailing list directly.

PS2: I heard that there's a GSoC student this year who's going to work on Inkscape's text implementation (fixing compliance issues to the SVG spec, I think...) It would be really great to keep in contact with him/her and the mentor to coordinate efforts.


2017-05-30 7:48 GMT-03:00 Khaled Hosny <[hidden email]>:
On Tue, May 30, 2017 at 12:35:24AM -0300, Felipe Sanches wrote:
> The relationship between pango and harfbuzz is still not very clear to me,
> as I have the impression that even pango_shape() invokes hb_shape() under
> the hood nowadays.

It will eventually call HarfBuzz on Linux, but in Windows and Mac it
will call Uniscribe and Core Text, respectively. Switching to HarfBuzz
on all platforms is kinda on Pango’s TODO list, but I don’t think anyone
is working on it currently.

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/googlefonts-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/20170530104838.GC24994%40macbook.
For more options, visit https://groups.google.com/d/optout.




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

Felipe Sanches-2
Today I continued working Variable Fonts support on Inkscape. More specifically, I focused on adding parsing/handling of the font-variation-settings property (CSS Fonts Module Level 4). The code is here:

https://gitlab.com/fsanches/inkscape/commit/2a6a42a1389eb29b3ac94c5db9321a72000b5bb5

A shortcoming of the above code is that it only deals with a single axis coordinate, while the CSS spec allows for an arbitrary number of axis names and correspondent design-space coordinates. I do have an uncommited draft of the SPIVariableFontAxisOrNormal class which uses a C++ std::map<Glib::ustring, SPILength> for storing the parsed key/values from the property, but that code is still work-in-progress and it is what I'll be working on tomorrow.

After getting that to work, I intend to modify the font_instance* font_factory::FaceFromStyle(SPStyle const *style) method to instantiate font_instance objects taking the newly parsed property values in consideration.

One next milestone could be to get a well-formed SVG file containing a bunch of different variable-font coordinates in several chunks of text declared using the CSS property to load and render properly (without bothering about an editing UI at first). And after that I can work on the UI and the harder problem of how to decide whether a new font_instance object should be created or whether it should be recicled upon user edits.

Please let me know if you think I'm doing something wrong here. The description above is my current understanding of a possible path towards an implementation of this feature. I'm open to getting feedback on that.

Happy Hacking,
Felipe Sanches

2017-06-10 2:35 GMT-03:00 Felipe Sanches <[hidden email]>:
Hi there!

I was expecting to get some feedback on this thread from other Inkscape developers, but still did not really get any. So I continued investigating the issue by myself. At the moment I'm mapping out where and how the font_instances are created, deleted and used throughout the code-base because any changes I make have to consider all side-effects that may surface. I did feel a bit overwhelmed at first with the complexity of the text-handling code, but I think I'm on the right track now.

To alleviate the anxiety of dealing with such a complex large-chunk of code, I got my hands dirty by refactoring a few portions of libnrtype/Layout-*.cpp files (it's like gardening: we can't keep just staring at it :-P) and I also talked to some friends. Since a few Brazilian friends shared the enthusiasm of OpenType Variable Fonts at LGM earlier this year here in Brazil, I wrote a bit about the ongoing effort at an online forum here: https://forum.fiozera.com.br/t/suporte-a-opentype-variable-fonts-no-inkscape/115 It is all in Brazilian Portuguese, sorry, so it is probably not much useful here, but it is also not much different from what I already talked about here in this email thread which is still the official place for me to provide progress updates. Also the forum thread does not cover a lot of areas of the code I've been studying. Writing at that forum was more of a way of relaxing and getting ideas to flow again. I'll probably do so again from time to time. :-)

Since Inkscape has finally migrated to git today ("upstream" repo is now at https://gitlab.com/inkscape/inkscape), I did fork it at https://gitlab.com/fsanches/inkscape and also got my user account approved with push-rights. I was an active Inkscape developer on Bazar several years ago with equivalent commit rights.

Then I tried the "Merge Requests" workflow, but then I figured that probably the Inkscape team will (at least for a while) prefer to work directly committing to the master branch, instead of opening requests for merge. I pushed to master a few of the aforementioned refactoring commits and created a "variable_fonts" branch on my local working copy where I'll resume all of the experimental OpenType coding (to avoid polluting master before the feature is ready to land).

So, next week I plan to get back to contributing to FontBakery ( https://github.com/googlefonts/fontbakery/ ) and gradually work a bit more on Inkscape as well. Exactly which of both tasks will take most of my time will depend on the availability of Lasse's upcoming FontBakery pull request and also on the level of feedback that I may (or may not) get from Inkscape developers. I guess perhaps no-one else who originally dealt with the text-handling code in Inkscape is active in the team nowadays ? If that's the case, then I'll have to really "take ownership" of that portion of code and improve it based on my best judgement of what would be the best approaches.

One final thing: I'm really interested in talking to whoever is planning to work on a text feature on Google Summer of Code this year. Who's the student ?! Please contact me.

Happy Hacking,
Felipe "Juca" Sanches

2017-06-05 17:57 GMT-03:00 Felipe Sanches <[hidden email]>:
I'm writing this message addressed both to UI-designers in general as well as (to some extent) to senior Inkscape developers who may provide some more feedback on the actual code.
====

My current understanding regarding variable fonts is that any time the user tweaks parameters in a variable font, Inkscape will have to decide whether to modify those design-space coordinates on the font instance associated with the currently selected chunk of text or to instantiate a new font_instance object. Here's my rationale behind this:

If the SVG document has the same font applied to more than a single chunk of text, then we need to create a new font instance so that the edits to one chunk of text won't affect other chunks that were previously sharing the same font_instance. That would work as a lazy "un-clone" of the font resource once the differentiation is really needed. It is good (in order to avoid wasting memory) to share a font_instance for chunks of text that use the same non-variable font, or that use the default design space coordinates of a given variable font.

I think that allowing variable font design-space tweaks to individual chunks of text is desirable from the user perspective and also required from the SVG spec perspective. The SVG spec does not talk about variable fonts, but it allows individual text chunks to have their own font-family and style attributes which then apparently means allowing them to have their own variable font design space coordinates as well (If I understood it correctly). I think this is analogous to individual paths having their own individual fill/stroke styles.

It just occurred to me that this leads to a possible confusion and we probably have to make a UI design choice here. There may be occasions when the user may want to modify the design-space coordinates of a given variable font globally on the document. Do you think this is a valid concern / valid usage scenario ? In that case, a variable font instance may behave like a shared resource, analogous to a shared gradient or filter-effect. But then we would need to make this an explicit user-choice, perhaps by providing a dedicated dialog for setting up such shared font resources. Like a "palette of font instances". Does it make sense ? Also, from a codebase point of view, would you suggest a prefered way to approach this? (Thinking about how to manage these variable-font instances)


2017-06-02 22:35 GMT-03:00 Felipe Sanches <[hidden email]>:
Hi there,

These past days I've been adding an experimental UI to Inkscape for tweaking parameters in OpenType variable fonts. One major roadblock I stumbled upon is requiring me to think more carefully about some potentially deeper architectural changes. In the screenshot attached to this message you can see some text written with the Decovar variable font. The slider labeled "Testing" in the "Text & Font" dialog is wired to invoke a callback upon value-change. This callback detects the currently selected font based on the canvas text-tool cursor position, retrieves the corresponding font_instance object and invokes Freetype's FT_Set_Var_Design_Coordinates method with the updated design-space coordinates (the slider in this experiment is hardwired to adjust the weight axis of Decovar).

(I really miss a Freetype method to alter a single design-space coordinate, instead of having to pass the full array, by the way)

The way things work right now, unfortunately, leads to the glyphs not changing on-canvas because once they are loaded, they seem to be kept in a cache. As you can see in the screenshot, each glyph has a different weigth, based on the slider setting when the glyph was loaded for the first time. It seems quite obvious that I should do something to invalidate the cache upon dragging the slider. But that, on the other hand, should not alter glyphs in other places where the same variable font is being used in the same document.

Based on all that, I think that the proper implementation would involve creating individual font_instance objects for each text chunk where a variable-font is used with non-default design-space coordinates so that they can be tweaked independently. Achieving that, though, will surely involve a bit deeper fiddling with Inkscape's text internals, which is what I expect to do in my next few days of work on this.

cheers,
Felipe Sanches

PS:
I'm crossposting this to the Inkscape-devel mailing list as the rest of the development community may be interested in receiving updates on this topic. I may as well move all future updates to the Inkscape mailing list directly.

PS2: I heard that there's a GSoC student this year who's going to work on Inkscape's text implementation (fixing compliance issues to the SVG spec, I think...) It would be really great to keep in contact with him/her and the mentor to coordinate efforts.


2017-05-30 7:48 GMT-03:00 Khaled Hosny <[hidden email]>:
On Tue, May 30, 2017 at 12:35:24AM -0300, Felipe Sanches wrote:
> The relationship between pango and harfbuzz is still not very clear to me,
> as I have the impression that even pango_shape() invokes hb_shape() under
> the hood nowadays.

It will eventually call HarfBuzz on Linux, but in Windows and Mac it
will call Uniscribe and Core Text, respectively. Switching to HarfBuzz
on all platforms is kinda on Pango’s TODO list, but I don’t think anyone
is working on it currently.

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/googlefonts-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/20170530104838.GC24994%40macbook.
For more options, visit https://groups.google.com/d/optout.





------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

Felipe Sanches-2
By the way... once I make the class handle multiple axis coordinates it would be reasonable for me to rename it from SPIVariableFontAxisOrNormal to SPIFontVariationSettings

2017-06-13 0:20 GMT-03:00 Felipe Sanches <[hidden email]>:
Today I continued working Variable Fonts support on Inkscape. More specifically, I focused on adding parsing/handling of the font-variation-settings property (CSS Fonts Module Level 4). The code is here:

https://gitlab.com/fsanches/inkscape/commit/2a6a42a1389eb29b3ac94c5db9321a72000b5bb5

A shortcoming of the above code is that it only deals with a single axis coordinate, while the CSS spec allows for an arbitrary number of axis names and correspondent design-space coordinates. I do have an uncommited draft of the SPIVariableFontAxisOrNormal class which uses a C++ std::map<Glib::ustring, SPILength> for storing the parsed key/values from the property, but that code is still work-in-progress and it is what I'll be working on tomorrow.

After getting that to work, I intend to modify the font_instance* font_factory::FaceFromStyle(SPStyle const *style) method to instantiate font_instance objects taking the newly parsed property values in consideration.

One next milestone could be to get a well-formed SVG file containing a bunch of different variable-font coordinates in several chunks of text declared using the CSS property to load and render properly (without bothering about an editing UI at first). And after that I can work on the UI and the harder problem of how to decide whether a new font_instance object should be created or whether it should be recicled upon user edits.

Please let me know if you think I'm doing something wrong here. The description above is my current understanding of a possible path towards an implementation of this feature. I'm open to getting feedback on that.

Happy Hacking,
Felipe Sanches

2017-06-10 2:35 GMT-03:00 Felipe Sanches <[hidden email]>:
Hi there!

I was expecting to get some feedback on this thread from other Inkscape developers, but still did not really get any. So I continued investigating the issue by myself. At the moment I'm mapping out where and how the font_instances are created, deleted and used throughout the code-base because any changes I make have to consider all side-effects that may surface. I did feel a bit overwhelmed at first with the complexity of the text-handling code, but I think I'm on the right track now.

To alleviate the anxiety of dealing with such a complex large-chunk of code, I got my hands dirty by refactoring a few portions of libnrtype/Layout-*.cpp files (it's like gardening: we can't keep just staring at it :-P) and I also talked to some friends. Since a few Brazilian friends shared the enthusiasm of OpenType Variable Fonts at LGM earlier this year here in Brazil, I wrote a bit about the ongoing effort at an online forum here: https://forum.fiozera.com.br/t/suporte-a-opentype-variable-fonts-no-inkscape/115 It is all in Brazilian Portuguese, sorry, so it is probably not much useful here, but it is also not much different from what I already talked about here in this email thread which is still the official place for me to provide progress updates. Also the forum thread does not cover a lot of areas of the code I've been studying. Writing at that forum was more of a way of relaxing and getting ideas to flow again. I'll probably do so again from time to time. :-)

Since Inkscape has finally migrated to git today ("upstream" repo is now at https://gitlab.com/inkscape/inkscape), I did fork it at https://gitlab.com/fsanches/inkscape and also got my user account approved with push-rights. I was an active Inkscape developer on Bazar several years ago with equivalent commit rights.

Then I tried the "Merge Requests" workflow, but then I figured that probably the Inkscape team will (at least for a while) prefer to work directly committing to the master branch, instead of opening requests for merge. I pushed to master a few of the aforementioned refactoring commits and created a "variable_fonts" branch on my local working copy where I'll resume all of the experimental OpenType coding (to avoid polluting master before the feature is ready to land).

So, next week I plan to get back to contributing to FontBakery ( https://github.com/googlefonts/fontbakery/ ) and gradually work a bit more on Inkscape as well. Exactly which of both tasks will take most of my time will depend on the availability of Lasse's upcoming FontBakery pull request and also on the level of feedback that I may (or may not) get from Inkscape developers. I guess perhaps no-one else who originally dealt with the text-handling code in Inkscape is active in the team nowadays ? If that's the case, then I'll have to really "take ownership" of that portion of code and improve it based on my best judgement of what would be the best approaches.

One final thing: I'm really interested in talking to whoever is planning to work on a text feature on Google Summer of Code this year. Who's the student ?! Please contact me.

Happy Hacking,
Felipe "Juca" Sanches

2017-06-05 17:57 GMT-03:00 Felipe Sanches <[hidden email]>:
I'm writing this message addressed both to UI-designers in general as well as (to some extent) to senior Inkscape developers who may provide some more feedback on the actual code.
====

My current understanding regarding variable fonts is that any time the user tweaks parameters in a variable font, Inkscape will have to decide whether to modify those design-space coordinates on the font instance associated with the currently selected chunk of text or to instantiate a new font_instance object. Here's my rationale behind this:

If the SVG document has the same font applied to more than a single chunk of text, then we need to create a new font instance so that the edits to one chunk of text won't affect other chunks that were previously sharing the same font_instance. That would work as a lazy "un-clone" of the font resource once the differentiation is really needed. It is good (in order to avoid wasting memory) to share a font_instance for chunks of text that use the same non-variable font, or that use the default design space coordinates of a given variable font.

I think that allowing variable font design-space tweaks to individual chunks of text is desirable from the user perspective and also required from the SVG spec perspective. The SVG spec does not talk about variable fonts, but it allows individual text chunks to have their own font-family and style attributes which then apparently means allowing them to have their own variable font design space coordinates as well (If I understood it correctly). I think this is analogous to individual paths having their own individual fill/stroke styles.

It just occurred to me that this leads to a possible confusion and we probably have to make a UI design choice here. There may be occasions when the user may want to modify the design-space coordinates of a given variable font globally on the document. Do you think this is a valid concern / valid usage scenario ? In that case, a variable font instance may behave like a shared resource, analogous to a shared gradient or filter-effect. But then we would need to make this an explicit user-choice, perhaps by providing a dedicated dialog for setting up such shared font resources. Like a "palette of font instances". Does it make sense ? Also, from a codebase point of view, would you suggest a prefered way to approach this? (Thinking about how to manage these variable-font instances)


2017-06-02 22:35 GMT-03:00 Felipe Sanches <[hidden email]>:
Hi there,

These past days I've been adding an experimental UI to Inkscape for tweaking parameters in OpenType variable fonts. One major roadblock I stumbled upon is requiring me to think more carefully about some potentially deeper architectural changes. In the screenshot attached to this message you can see some text written with the Decovar variable font. The slider labeled "Testing" in the "Text & Font" dialog is wired to invoke a callback upon value-change. This callback detects the currently selected font based on the canvas text-tool cursor position, retrieves the corresponding font_instance object and invokes Freetype's FT_Set_Var_Design_Coordinates method with the updated design-space coordinates (the slider in this experiment is hardwired to adjust the weight axis of Decovar).

(I really miss a Freetype method to alter a single design-space coordinate, instead of having to pass the full array, by the way)

The way things work right now, unfortunately, leads to the glyphs not changing on-canvas because once they are loaded, they seem to be kept in a cache. As you can see in the screenshot, each glyph has a different weigth, based on the slider setting when the glyph was loaded for the first time. It seems quite obvious that I should do something to invalidate the cache upon dragging the slider. But that, on the other hand, should not alter glyphs in other places where the same variable font is being used in the same document.

Based on all that, I think that the proper implementation would involve creating individual font_instance objects for each text chunk where a variable-font is used with non-default design-space coordinates so that they can be tweaked independently. Achieving that, though, will surely involve a bit deeper fiddling with Inkscape's text internals, which is what I expect to do in my next few days of work on this.

cheers,
Felipe Sanches

PS:
I'm crossposting this to the Inkscape-devel mailing list as the rest of the development community may be interested in receiving updates on this topic. I may as well move all future updates to the Inkscape mailing list directly.

PS2: I heard that there's a GSoC student this year who's going to work on Inkscape's text implementation (fixing compliance issues to the SVG spec, I think...) It would be really great to keep in contact with him/her and the mentor to coordinate efforts.


2017-05-30 7:48 GMT-03:00 Khaled Hosny <[hidden email]>:
On Tue, May 30, 2017 at 12:35:24AM -0300, Felipe Sanches wrote:
> The relationship between pango and harfbuzz is still not very clear to me,
> as I have the impression that even pango_shape() invokes hb_shape() under
> the hood nowadays.

It will eventually call HarfBuzz on Linux, but in Windows and Mac it
will call Uniscribe and Core Text, respectively. Switching to HarfBuzz
on all platforms is kinda on Pango’s TODO list, but I don’t think anyone
is working on it currently.

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/googlefonts-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/20170530104838.GC24994%40macbook.
For more options, visit https://groups.google.com/d/optout.






------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

Felipe Sanches-2
And, for the record, this is the URL for the definition of this property on the spec:
https://drafts.csswg.org/css-fonts-4/#font-variation-settings-def

2017-06-13 0:23 GMT-03:00 Felipe Sanches <[hidden email]>:
By the way... once I make the class handle multiple axis coordinates it would be reasonable for me to rename it from SPIVariableFontAxisOrNormal to SPIFontVariationSettings

2017-06-13 0:20 GMT-03:00 Felipe Sanches <[hidden email]>:
Today I continued working Variable Fonts support on Inkscape. More specifically, I focused on adding parsing/handling of the font-variation-settings property (CSS Fonts Module Level 4). The code is here:

https://gitlab.com/fsanches/inkscape/commit/2a6a42a1389eb29b3ac94c5db9321a72000b5bb5

A shortcoming of the above code is that it only deals with a single axis coordinate, while the CSS spec allows for an arbitrary number of axis names and correspondent design-space coordinates. I do have an uncommited draft of the SPIVariableFontAxisOrNormal class which uses a C++ std::map<Glib::ustring, SPILength> for storing the parsed key/values from the property, but that code is still work-in-progress and it is what I'll be working on tomorrow.

After getting that to work, I intend to modify the font_instance* font_factory::FaceFromStyle(SPStyle const *style) method to instantiate font_instance objects taking the newly parsed property values in consideration.

One next milestone could be to get a well-formed SVG file containing a bunch of different variable-font coordinates in several chunks of text declared using the CSS property to load and render properly (without bothering about an editing UI at first). And after that I can work on the UI and the harder problem of how to decide whether a new font_instance object should be created or whether it should be recicled upon user edits.

Please let me know if you think I'm doing something wrong here. The description above is my current understanding of a possible path towards an implementation of this feature. I'm open to getting feedback on that.

Happy Hacking,
Felipe Sanches

2017-06-10 2:35 GMT-03:00 Felipe Sanches <[hidden email]>:
Hi there!

I was expecting to get some feedback on this thread from other Inkscape developers, but still did not really get any. So I continued investigating the issue by myself. At the moment I'm mapping out where and how the font_instances are created, deleted and used throughout the code-base because any changes I make have to consider all side-effects that may surface. I did feel a bit overwhelmed at first with the complexity of the text-handling code, but I think I'm on the right track now.

To alleviate the anxiety of dealing with such a complex large-chunk of code, I got my hands dirty by refactoring a few portions of libnrtype/Layout-*.cpp files (it's like gardening: we can't keep just staring at it :-P) and I also talked to some friends. Since a few Brazilian friends shared the enthusiasm of OpenType Variable Fonts at LGM earlier this year here in Brazil, I wrote a bit about the ongoing effort at an online forum here: https://forum.fiozera.com.br/t/suporte-a-opentype-variable-fonts-no-inkscape/115 It is all in Brazilian Portuguese, sorry, so it is probably not much useful here, but it is also not much different from what I already talked about here in this email thread which is still the official place for me to provide progress updates. Also the forum thread does not cover a lot of areas of the code I've been studying. Writing at that forum was more of a way of relaxing and getting ideas to flow again. I'll probably do so again from time to time. :-)

Since Inkscape has finally migrated to git today ("upstream" repo is now at https://gitlab.com/inkscape/inkscape), I did fork it at https://gitlab.com/fsanches/inkscape and also got my user account approved with push-rights. I was an active Inkscape developer on Bazar several years ago with equivalent commit rights.

Then I tried the "Merge Requests" workflow, but then I figured that probably the Inkscape team will (at least for a while) prefer to work directly committing to the master branch, instead of opening requests for merge. I pushed to master a few of the aforementioned refactoring commits and created a "variable_fonts" branch on my local working copy where I'll resume all of the experimental OpenType coding (to avoid polluting master before the feature is ready to land).

So, next week I plan to get back to contributing to FontBakery ( https://github.com/googlefonts/fontbakery/ ) and gradually work a bit more on Inkscape as well. Exactly which of both tasks will take most of my time will depend on the availability of Lasse's upcoming FontBakery pull request and also on the level of feedback that I may (or may not) get from Inkscape developers. I guess perhaps no-one else who originally dealt with the text-handling code in Inkscape is active in the team nowadays ? If that's the case, then I'll have to really "take ownership" of that portion of code and improve it based on my best judgement of what would be the best approaches.

One final thing: I'm really interested in talking to whoever is planning to work on a text feature on Google Summer of Code this year. Who's the student ?! Please contact me.

Happy Hacking,
Felipe "Juca" Sanches

2017-06-05 17:57 GMT-03:00 Felipe Sanches <[hidden email]>:
I'm writing this message addressed both to UI-designers in general as well as (to some extent) to senior Inkscape developers who may provide some more feedback on the actual code.
====

My current understanding regarding variable fonts is that any time the user tweaks parameters in a variable font, Inkscape will have to decide whether to modify those design-space coordinates on the font instance associated with the currently selected chunk of text or to instantiate a new font_instance object. Here's my rationale behind this:

If the SVG document has the same font applied to more than a single chunk of text, then we need to create a new font instance so that the edits to one chunk of text won't affect other chunks that were previously sharing the same font_instance. That would work as a lazy "un-clone" of the font resource once the differentiation is really needed. It is good (in order to avoid wasting memory) to share a font_instance for chunks of text that use the same non-variable font, or that use the default design space coordinates of a given variable font.

I think that allowing variable font design-space tweaks to individual chunks of text is desirable from the user perspective and also required from the SVG spec perspective. The SVG spec does not talk about variable fonts, but it allows individual text chunks to have their own font-family and style attributes which then apparently means allowing them to have their own variable font design space coordinates as well (If I understood it correctly). I think this is analogous to individual paths having their own individual fill/stroke styles.

It just occurred to me that this leads to a possible confusion and we probably have to make a UI design choice here. There may be occasions when the user may want to modify the design-space coordinates of a given variable font globally on the document. Do you think this is a valid concern / valid usage scenario ? In that case, a variable font instance may behave like a shared resource, analogous to a shared gradient or filter-effect. But then we would need to make this an explicit user-choice, perhaps by providing a dedicated dialog for setting up such shared font resources. Like a "palette of font instances". Does it make sense ? Also, from a codebase point of view, would you suggest a prefered way to approach this? (Thinking about how to manage these variable-font instances)


2017-06-02 22:35 GMT-03:00 Felipe Sanches <[hidden email]>:
Hi there,

These past days I've been adding an experimental UI to Inkscape for tweaking parameters in OpenType variable fonts. One major roadblock I stumbled upon is requiring me to think more carefully about some potentially deeper architectural changes. In the screenshot attached to this message you can see some text written with the Decovar variable font. The slider labeled "Testing" in the "Text & Font" dialog is wired to invoke a callback upon value-change. This callback detects the currently selected font based on the canvas text-tool cursor position, retrieves the corresponding font_instance object and invokes Freetype's FT_Set_Var_Design_Coordinates method with the updated design-space coordinates (the slider in this experiment is hardwired to adjust the weight axis of Decovar).

(I really miss a Freetype method to alter a single design-space coordinate, instead of having to pass the full array, by the way)

The way things work right now, unfortunately, leads to the glyphs not changing on-canvas because once they are loaded, they seem to be kept in a cache. As you can see in the screenshot, each glyph has a different weigth, based on the slider setting when the glyph was loaded for the first time. It seems quite obvious that I should do something to invalidate the cache upon dragging the slider. But that, on the other hand, should not alter glyphs in other places where the same variable font is being used in the same document.

Based on all that, I think that the proper implementation would involve creating individual font_instance objects for each text chunk where a variable-font is used with non-default design-space coordinates so that they can be tweaked independently. Achieving that, though, will surely involve a bit deeper fiddling with Inkscape's text internals, which is what I expect to do in my next few days of work on this.

cheers,
Felipe Sanches

PS:
I'm crossposting this to the Inkscape-devel mailing list as the rest of the development community may be interested in receiving updates on this topic. I may as well move all future updates to the Inkscape mailing list directly.

PS2: I heard that there's a GSoC student this year who's going to work on Inkscape's text implementation (fixing compliance issues to the SVG spec, I think...) It would be really great to keep in contact with him/her and the mentor to coordinate efforts.


2017-05-30 7:48 GMT-03:00 Khaled Hosny <[hidden email]>:
On Tue, May 30, 2017 at 12:35:24AM -0300, Felipe Sanches wrote:
> The relationship between pango and harfbuzz is still not very clear to me,
> as I have the impression that even pango_shape() invokes hb_shape() under
> the hood nowadays.

It will eventually call HarfBuzz on Linux, but in Windows and Mac it
will call Uniscribe and Core Text, respectively. Switching to HarfBuzz
on all platforms is kinda on Pango’s TODO list, but I don’t think anyone
is working on it currently.

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/googlefonts-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/20170530104838.GC24994%40macbook.
For more options, visit https://groups.google.com/d/optout.







------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

Jabier Arraiza
In reply to this post by Felipe Sanches-2
Better!
On Tue, 2017-06-13 at 00:23 -0300, Felipe Sanches wrote:

> By the way... once I make the class handle multiple axis coordinates
> it
> would be reasonable for me to rename it from
> *SPIVariableFontAxisOrNormal*
> to *SPIFontVariationSettings*
>
> 2017-06-13 0:20 GMT-03:00 Felipe Sanches <[hidden email]>:
>
> > Today I continued working Variable Fonts support on Inkscape. More
> > specifically, I focused on adding parsing/handling of the
> > *font-variation-settings* property (CSS Fonts Module Level 4). The
> > code
> > is here:
> >
> > https://gitlab.com/fsanches/inkscape/commit/2a6a42a1389eb29b3ac94c5
> > db9321a
> > 72000b5bb5
> >
> > A shortcoming of the above code is that it only deals with a single
> > axis
> > coordinate, while the CSS spec allows for an arbitrary number of
> > axis names
> > and correspondent design-space coordinates. I do have an uncommited
> > draft
> > of the *SPIVariableFontAxisOrNormal* class which uses a C++
> > *std::map<Glib::ustring,
> > SPILength>* for storing the parsed key/values from the property,
> > but that
> > code is still work-in-progress and it is what I'll be working on
> > tomorrow.
> >
> > After getting that to work, I intend to modify the *font_instance*
> > font_factory::FaceFromStyle(SPStyle const *style)* method to
> > instantiate
> > font_instance objects taking the newly parsed property values in
> > consideration.
> >
> > One next milestone could be to get a well-formed SVG file
> > containing a
> > bunch of different variable-font coordinates in several chunks of
> > text
> > declared using the CSS property to load and render properly
> > (without
> > bothering about an editing UI at first). And after that I can work
> > on the
> > UI and the harder problem of how to decide whether a new
> > font_instance
> > object should be created or whether it should be recicled upon user
> > edits.
> >
> > Please let me know if you think I'm doing something wrong here. The
> > description above is my current understanding of a possible path
> > towards an
> > implementation of this feature. I'm open to getting feedback on
> > that.
> >
> > Happy Hacking,
> > Felipe Sanches
> >
> > 2017-06-10 2:35 GMT-03:00 Felipe Sanches <[hidden email]>:
> >
> > > Hi there!
> > >
> > > I was expecting to get some feedback on this thread from other
> > > Inkscape
> > > developers, but still did not really get any. So I continued
> > > investigating
> > > the issue by myself. At the moment I'm mapping out where and how
> > > the
> > > font_instances are created, deleted and used throughout the code-
> > > base
> > > because any changes I make have to consider all side-effects that
> > > may
> > > surface. I did feel a bit overwhelmed at first with the
> > > complexity of the
> > > text-handling code, but I think I'm on the right track now.
> > >
> > > To alleviate the anxiety of dealing with such a complex large-
> > > chunk of
> > > code, I got my hands dirty by refactoring a few portions of
> > > libnrtype/Layout-*.cpp files (it's like gardening: we can't keep
> > > just
> > > staring at it :-P) and I also talked to some friends. Since a few
> > > Brazilian
> > > friends shared the enthusiasm of OpenType Variable Fonts at LGM
> > > earlier
> > > this year here in Brazil, I wrote a bit about the ongoing effort
> > > at an
> > > online forum here: https://forum.fiozera.com.br/t
> > > /suporte-a-opentype-variable-fonts-no-inkscape/115 It is all in
> > > Brazilian Portuguese, sorry, so it is probably not much useful
> > > here, but it
> > > is also not much different from what I already talked about here
> > > in this
> > > email thread which is still the official place for me to provide
> > > progress
> > > updates. Also the forum thread does not cover a lot of areas of
> > > the code
> > > I've been studying. Writing at that forum was more of a way of
> > > relaxing and
> > > getting ideas to flow again. I'll probably do so again from time
> > > to time.
> > > :-)
> > >
> > > Since Inkscape has finally migrated to git today ("upstream" repo
> > > is now
> > > at https://gitlab.com/inkscape/inkscape), I did fork it at
> > > https://gitlab.com/fsanches/inkscape and also got my user account
> > > approved with push-rights. I was an active Inkscape developer on
> > > Bazar
> > > several years ago with equivalent commit rights.
> > >
> > > Then I tried the "Merge Requests" workflow, but then I figured
> > > that
> > > probably the Inkscape team will (at least for a while) prefer to
> > > work
> > > directly committing to the master branch, instead of opening
> > > requests for
> > > merge. I pushed to master a few of the aforementioned refactoring
> > > commits
> > > and created a "variable_fonts" branch on my local working copy
> > > where I'll
> > > resume all of the experimental OpenType coding (to avoid
> > > polluting master
> > > before the feature is ready to land).
> > >
> > > So, next week I plan to get back to contributing to FontBakery (
> > > https://github.com/googlefonts/fontbakery/ ) and gradually work a
> > > bit
> > > more on Inkscape as well. Exactly which of both tasks will take
> > > most of my
> > > time will depend on the availability of Lasse's upcoming
> > > FontBakery pull
> > > request and also on the level of feedback that I may (or may not)
> > > get from
> > > Inkscape developers. I guess perhaps no-one else who originally
> > > dealt with
> > > the text-handling code in Inkscape is active in the team nowadays
> > > ? If
> > > that's the case, then I'll have to really "take ownership" of
> > > that portion
> > > of code and improve it based on my best judgement of what would
> > > be the best
> > > approaches.
> > >
> > > One final thing: I'm really interested in talking to whoever is
> > > planning
> > > to work on a text feature on Google Summer of Code this year.
> > > Who's the
> > > student ?! Please contact me.
> > >
> > > Happy Hacking,
> > > Felipe "Juca" Sanches
> > >
> > > 2017-06-05 17:57 GMT-03:00 Felipe Sanches <[hidden email]>:
> > >
> > > > I'm writing this message addressed both to UI-designers in
> > > > general as
> > > > well as (to some extent) to senior Inkscape developers who may
> > > > provide some
> > > > more feedback on the actual code.
> > > > ====
> > > >
> > > > My current understanding regarding variable fonts is that any
> > > > time the
> > > > user tweaks parameters in a variable font, Inkscape will have
> > > > to decide
> > > > whether to modify those design-space coordinates on the font
> > > > instance
> > > > associated with the currently selected chunk of text or to
> > > > instantiate a
> > > > new font_instance object. Here's my rationale behind this:
> > > >
> > > > If the SVG document has the same font applied to more than a
> > > > single
> > > > chunk of text, then we need to create a new font instance so
> > > > that the edits
> > > > to one chunk of text won't affect other chunks that were
> > > > previously sharing
> > > > the same font_instance. That would work as a lazy "un-clone" of
> > > > the font
> > > > resource once the differentiation is really needed. It is good
> > > > (in order to
> > > > avoid wasting memory) to share a font_instance for chunks of
> > > > text that use
> > > > the same non-variable font, or that use the default design
> > > > space
> > > > coordinates of a given variable font.
> > > >
> > > > I think that allowing variable font design-space tweaks to
> > > > individual
> > > > chunks of text is desirable from the user perspective and also
> > > > required
> > > > from the SVG spec perspective. The SVG spec does not talk about
> > > > variable
> > > > fonts, but it allows individual text chunks to have their own
> > > > font-family
> > > > and style attributes which then apparently means allowing them
> > > > to have
> > > > their own variable font design space coordinates as well (If I
> > > > understood
> > > > it correctly). I think this is analogous to individual paths
> > > > having their
> > > > own individual fill/stroke styles.
> > > >
> > > > It just occurred to me that this leads to a possible confusion
> > > > and we
> > > > probably have to make a UI design choice here. There may be
> > > > occasions when
> > > > the user may want to modify the design-space coordinates of a
> > > > given
> > > > variable font globally on the document. Do you think this is a
> > > > valid
> > > > concern / valid usage scenario ? In that case, a variable font
> > > > instance may
> > > > behave like a shared resource, analogous to a shared gradient
> > > > or
> > > > filter-effect. But then we would need to make this an explicit
> > > > user-choice,
> > > > perhaps by providing a dedicated dialog for setting up such
> > > > shared font
> > > > resources. Like a "palette of font instances". Does it make
> > > > sense ? Also,
> > > > from a codebase point of view, would you suggest a prefered way
> > > > to approach
> > > > this? (Thinking about how to manage these variable-font
> > > > instances)
> > > >
> > > >
> > > > 2017-06-02 22:35 GMT-03:00 Felipe Sanches <[hidden email]
> > > > >:
> > > >
> > > > > Hi there,
> > > > >
> > > > > These past days I've been adding an experimental UI to
> > > > > Inkscape for
> > > > > tweaking parameters in OpenType variable fonts. One major
> > > > > roadblock I
> > > > > stumbled upon is requiring me to think more carefully about
> > > > > some
> > > > > potentially deeper architectural changes. In the screenshot
> > > > > attached to
> > > > > this message you can see some text written with the Decovar
> > > > > variable font.
> > > > > The slider labeled "Testing" in the "Text & Font" dialog is
> > > > > wired to invoke
> > > > > a callback upon value-change. This callback detects the
> > > > > currently selected
> > > > > font based on the canvas text-tool cursor position, retrieves
> > > > > the
> > > > > corresponding font_instance object and invokes Freetype's
> > > > > FT_Set_Var_Design_Coordinates method with the updated design-
> > > > > space
> > > > > coordinates (the slider in this experiment is hardwired to
> > > > > adjust the
> > > > > weight axis of Decovar).
> > > > >
> > > > > (I really miss a Freetype method to alter a single design-
> > > > > space
> > > > > coordinate, instead of having to pass the full array, by the
> > > > > way)
> > > > >
> > > > > The way things work right now, unfortunately, leads to the
> > > > > glyphs not
> > > > > changing on-canvas because once they are loaded, they seem to
> > > > > be kept in a
> > > > > cache. As you can see in the screenshot, each glyph has a
> > > > > different weigth,
> > > > > based on the slider setting when the glyph was loaded for the
> > > > > first time.
> > > > > It seems quite obvious that I should do something to
> > > > > invalidate the cache
> > > > > upon dragging the slider. But that, on the other hand, should
> > > > > not alter
> > > > > glyphs in other places where the same variable font is being
> > > > > used in the
> > > > > same document.
> > > > >
> > > > > Based on all that, I think that the proper implementation
> > > > > would involve
> > > > > creating individual font_instance objects for each text chunk
> > > > > where a
> > > > > variable-font is used with non-default design-space
> > > > > coordinates so that
> > > > > they can be tweaked independently. Achieving that, though,
> > > > > will surely
> > > > > involve a bit deeper fiddling with Inkscape's text internals,
> > > > > which is what
> > > > > I expect to do in my next few days of work on this.
> > > > >
> > > > > cheers,
> > > > > Felipe Sanches
> > > > >
> > > > > PS:
> > > > > I'm crossposting this to the Inkscape-devel mailing list as
> > > > > the rest of
> > > > > the development community may be interested in receiving
> > > > > updates on this
> > > > > topic. I may as well move all future updates to the Inkscape
> > > > > mailing list
> > > > > directly.
> > > > >
> > > > > PS2: I heard that there's a GSoC student this year who's
> > > > > going to work
> > > > > on Inkscape's text implementation (fixing compliance issues
> > > > > to the SVG
> > > > > spec, I think...) It would be really great to keep in contact
> > > > > with him/her
> > > > > and the mentor to coordinate efforts.
> > > > >
> > > > >
> > > > > 2017-05-30 7:48 GMT-03:00 Khaled Hosny <[hidden email]
> > > > > >:
> > > > >
> > > > > > On Tue, May 30, 2017 at 12:35:24AM -0300, Felipe Sanches
> > > > > > wrote:
> > > > > > > The relationship between pango and harfbuzz is still not
> > > > > > > very clear
> > > > > >
> > > > > > to me,
> > > > > > > as I have the impression that even pango_shape() invokes
> > > > > > > hb_shape()
> > > > > >
> > > > > > under
> > > > > > > the hood nowadays.
> > > > > >
> > > > > > It will eventually call HarfBuzz on Linux, but in Windows
> > > > > > and Mac it
> > > > > > will call Uniscribe and Core Text, respectively. Switching
> > > > > > to HarfBuzz
> > > > > > on all platforms is kinda on Pango’s TODO list, but I don’t
> > > > > > think
> > > > > > anyone
> > > > > > is working on it currently.
> > > > > >
> > > > > > --
> > > > > > You received this message because you are subscribed to the
> > > > > > Google
> > > > > > Groups "Google Fonts Discussions" group.
> > > > > > To unsubscribe from this group and stop receiving emails
> > > > > > from it, send
> > > > > > an email to [hidden email]
> > > > > > m.
> > > > > > To post to this group, send email to googlefonts-discuss@go
> > > > > > oglegrou
> > > > > > ps.com.
> > > > > > Visit this group at https://groups.google.com/grou
> > > > > > p/googlefonts-discuss.
> > > > > > To view this discussion on the web visit
> > > > > > https://groups.google.com/d/msgid/googlefonts-discuss/20170
> > > > > > 5
> > > > > > 30104838.GC24994%40macbook.
> > > > > > For more options, visit https://groups.google.com/d/optout.
> > > > > >
> > > > >
> > > > >
>
> -------------------------------------------------------------------
> -----------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Inkscape-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

Tavmjong Bah
In reply to this post by Felipe Sanches-2
On Tue, 2017-06-13 at 00:23 -0300, Felipe Sanches wrote:
By the way... once I make the class handle multiple axis coordinates it would be reasonable for me to rename it from SPIVariableFontAxisOrNormal to SPIFontVariationSettings

'SPIFontVariationSettings' follows the rule for one-off classes: 'SPI' + property name in CamelCase.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

Dave Crossland
In reply to this post by Felipe Sanches-2


On Jun 5, 2017 4:57 PM, "Felipe Sanches" <[hidden email]> wrote:
There may be occasions when the user may want to modify the design-space coordinates of a given variable font globally on the document. Do you think this is a valid concern / valid usage scenario ?

I think you should postpone this for now and consider it a future possible milestone. 

In that case, a variable font instance may behave like a shared resource, analogous to a shared gradient or filter-effect. But then we would need to make this an explicit user-choice, perhaps by providing a dedicated dialog for setting up such shared font resources. Like a "palette of font instances". Does it make sense ? 

Yes, more sophisticated typesetting environments have "character styles" and "paragraph styles" which are such palettes and afaik inkscape doesn't have a UI for that. 

Cheers
Dave

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

Felipe Sanches-2
Cool!

I would just avoid using the term "palette" because I recently learned that the term "font-palette" is used in the CSS spec for something else (relating to color palettes in coloured font faces).

As can be seen here:
https://drafts.csswg.org/css-fonts-4/#font-palette-prop

2017-06-13 9:20 GMT-03:00 Dave Crossland <[hidden email]>:


On Jun 5, 2017 4:57 PM, "Felipe Sanches" <[hidden email]> wrote:
There may be occasions when the user may want to modify the design-space coordinates of a given variable font globally on the document. Do you think this is a valid concern / valid usage scenario ?

I think you should postpone this for now and consider it a future possible milestone. 

In that case, a variable font instance may behave like a shared resource, analogous to a shared gradient or filter-effect. But then we would need to make this an explicit user-choice, perhaps by providing a dedicated dialog for setting up such shared font resources. Like a "palette of font instances". Does it make sense ? 

Yes, more sophisticated typesetting environments have "character styles" and "paragraph styles" which are such palettes and afaik inkscape doesn't have a UI for that. 

Cheers
Dave

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/googlefonts-discuss.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/CAEozd0yg2SeYO00d9Mq7pETmPQMFJ8n30B6sg-fpbhofBqW9Ng%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

Felipe Sanches-2
I've hit a roadblock / mental exhaustion from dealing with (banging my
head against) the Inkscape codebase, so I think it is very much wiser
to switch gears at the moment and do some FontBakery work again for a
while. And possibly get back to Inkscape later for a fresh restart.
I'll take a look now at what's pending on the issue tracker for
FontBakery that may be safe to work on regardless of Lasse's upcoming
PR.

Last week I should have met with Tav on a chat channel (possibly IRC)
but we ended up not being able to arrange a good time for that yet. So
I'm still going to get some feedback/advice from him at some point in
the future.

ScislaC (Josh Andler) on Inkscape IRC told me that not much people
touched the text-handling code in the past decade and that Tav is
probably the person who best knows it nowadays. So talking to him will
probably be very good. I don't want to continue digging deeper in that
code before talking to him, for instance.

I sketched a bit of each portion of the code that we need: (a) CSS
attribute parsing, (b) some GTK dialog/widgets and (c) some freetype
API calls for rendering the variable fonts. What I still lack is a
broader overview on how all of this stitches together coherently.

The concept is not much complicated. Read coordinate values from the
SVG file (as CSS attribute values), populate the UI of a dialog with
sliders, and then use that info when creating font instances. Then use
those values also to setup the appropriate freetype API calls. But the
devil is in the details. Among this, there's a whole labyrinth of code
for CSS and text handling...

Felipe Sanches


2017-06-13 9:37 GMT-03:00 Felipe Sanches <[hidden email]>:

> Cool!
>
> I would just avoid using the term "palette" because I recently learned that
> the term "font-palette" is used in the CSS spec for something else (relating
> to color palettes in coloured font faces).
>
> As can be seen here:
> https://drafts.csswg.org/css-fonts-4/#font-palette-prop
>
> 2017-06-13 9:20 GMT-03:00 Dave Crossland <[hidden email]>:
>>
>>
>>
>> On Jun 5, 2017 4:57 PM, "Felipe Sanches" <[hidden email]> wrote:
>>
>> There may be occasions when the user may want to modify the design-space
>> coordinates of a given variable font globally on the document. Do you think
>> this is a valid concern / valid usage scenario ?
>>
>>
>> I think you should postpone this for now and consider it a future possible
>> milestone.
>>
>> In that case, a variable font instance may behave like a shared resource,
>> analogous to a shared gradient or filter-effect. But then we would need to
>> make this an explicit user-choice, perhaps by providing a dedicated dialog
>> for setting up such shared font resources. Like a "palette of font
>> instances". Does it make sense ?
>>
>>
>> Yes, more sophisticated typesetting environments have "character styles"
>> and "paragraph styles" which are such palettes and afaik inkscape doesn't
>> have a UI for that.
>>
>> Cheers
>> Dave
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google Fonts Discussions" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [hidden email].
>> To post to this group, send email to [hidden email].
>> Visit this group at https://groups.google.com/group/googlefonts-discuss.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/googlefonts-discuss/CAEozd0yg2SeYO00d9Mq7pETmPQMFJ8n30B6sg-fpbhofBqW9Ng%40mail.gmail.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

Martin Owens-2
Hi Felipe,

Don't worry about getting stressed out with the Inkscape code base.
It's really big, and parts of it like text are the most intricate. Some
of that is there because it deals with a lot of features and/or
formatting of svg.

Take a break, have a breather. It might take another deep delve at the
coal face when you feel positive about learning a bunch of things and
being prepared to move the code towards refactoring if necessary.

Good luck!

Best Regards, Martin Owens

On Wed, 2017-06-21 at 00:00 -0300, Felipe Sanches wrote:
> I've hit a roadblock / mental exhaustion from dealing with (banging
> my
> head against) the Inkscape codebase, so I think it is very much wiser
> to switch gears at the moment and do some FontBakery work again for a
> while. And possibly get back to Inkscape later for a fresh restart.
> I'll take a look now at what's pending on the issue tracker for
> FontBakery that may be safe to work on regardless of Lasse's upcoming
> PR.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

Felipe Sanches-2
Thanks a lot for the supportive and kind words, Martin! I'll surely
give it a second chance soon. I gotta say that I'm pretty psyched
about the new OpenType Variable Fonts technology, so I'd love to help
make it happen on Inkscape at some point.

happy hacking,
Felipe Sanches

2017-06-21 0:25 GMT-03:00 Martin Owens <[hidden email]>:

> Hi Felipe,
>
> Don't worry about getting stressed out with the Inkscape code base.
> It's really big, and parts of it like text are the most intricate. Some
> of that is there because it deals with a lot of features and/or
> formatting of svg.
>
> Take a break, have a breather. It might take another deep delve at the
> coal face when you feel positive about learning a bunch of things and
> being prepared to move the code towards refactoring if necessary.
>
> Good luck!
>
> Best Regards, Martin Owens
>
> On Wed, 2017-06-21 at 00:00 -0300, Felipe Sanches wrote:
>> I've hit a roadblock / mental exhaustion from dealing with (banging
>> my
>> head against) the Inkscape codebase, so I think it is very much wiser
>> to switch gears at the moment and do some FontBakery work again for a
>> while. And possibly get back to Inkscape later for a fresh restart.
>> I'll take a look now at what's pending on the issue tracker for
>> FontBakery that may be safe to work on regardless of Lasse's upcoming
>> PR.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

Tavmjong Bah
In reply to this post by Felipe Sanches-2

Hi Felipe,

Sorry to miss you on IRC. I'm in the CEST time zone (UTC+2) and am
normally around between 9AM to 9PM (off and on).

I am probably the person that knows the text code the best... which is
a bit scary.

If Pango/HarfBuzz handles the variable font stuff then it shouldn't be
too hard to get rendering working. You can have a look at how the
OpenType stuff works, especially the 'getFontFeatureString() in
style.cpp and Layout-TNG-Compute.cpp.

Tav

On Wed, 2017-06-21 at 00:00 -0300, Felipe Sanches wrote:

> I've hit a roadblock / mental exhaustion from dealing with (banging
> my
> head against) the Inkscape codebase, so I think it is very much wiser
> to switch gears at the moment and do some FontBakery work again for a
> while. And possibly get back to Inkscape later for a fresh restart.
> I'll take a look now at what's pending on the issue tracker for
> FontBakery that may be safe to work on regardless of Lasse's upcoming
> PR.
>
> Last week I should have met with Tav on a chat channel (possibly IRC)
> but we ended up not being able to arrange a good time for that yet.
> So
> I'm still going to get some feedback/advice from him at some point in
> the future.
>
> ScislaC (Josh Andler) on Inkscape IRC told me that not much people
> touched the text-handling code in the past decade and that Tav is
> probably the person who best knows it nowadays. So talking to him
> will
> probably be very good. I don't want to continue digging deeper in
> that
> code before talking to him, for instance.
>
> I sketched a bit of each portion of the code that we need: (a) CSS
> attribute parsing, (b) some GTK dialog/widgets and (c) some freetype
> API calls for rendering the variable fonts. What I still lack is a
> broader overview on how all of this stitches together coherently.
>
> The concept is not much complicated. Read coordinate values from the
> SVG file (as CSS attribute values), populate the UI of a dialog with
> sliders, and then use that info when creating font instances. Then
> use
> those values also to setup the appropriate freetype API calls. But
> the
> devil is in the details. Among this, there's a whole labyrinth of
> code
> for CSS and text handling...
>
> Felipe Sanches
>
>
> 2017-06-13 9:37 GMT-03:00 Felipe Sanches <[hidden email]>:
> > Cool!
> >
> > I would just avoid using the term "palette" because I recently
> > learned that
> > the term "font-palette" is used in the CSS spec for something else
> > (relating
> > to color palettes in coloured font faces).
> >
> > As can be seen here:
> > https://drafts.csswg.org/css-fonts-4/#font-palette-prop
> >
> > 2017-06-13 9:20 GMT-03:00 Dave Crossland <[hidden email]>:
> > >
> > >
> > >
> > > On Jun 5, 2017 4:57 PM, "Felipe Sanches" <[hidden email]>
> > > wrote:
> > >
> > > There may be occasions when the user may want to modify the
> > > design-space
> > > coordinates of a given variable font globally on the document. Do
> > > you think
> > > this is a valid concern / valid usage scenario ?
> > >
> > >
> > > I think you should postpone this for now and consider it a future
> > > possible
> > > milestone.
> > >
> > > In that case, a variable font instance may behave like a shared
> > > resource,
> > > analogous to a shared gradient or filter-effect. But then we
> > > would need to
> > > make this an explicit user-choice, perhaps by providing a
> > > dedicated dialog
> > > for setting up such shared font resources. Like a "palette of
> > > font
> > > instances". Does it make sense ?
> > >
> > >
> > > Yes, more sophisticated typesetting environments have "character
> > > styles"
> > > and "paragraph styles" which are such palettes and afaik inkscape
> > > doesn't
> > > have a UI for that.
> > >
> > > Cheers
> > > Dave
> > >
> > > --
> > > You received this message because you are subscribed to the
> > > Google Groups
> > > "Google Fonts Discussions" group.
> > > To unsubscribe from this group and stop receiving emails from it,
> > > send an
> > > email to [hidden email].
> > > To post to this group, send email to googlefonts-discuss@googlegr
> > > oups.com.
> > > Visit this group at https://groups.google.com/group/googlefonts-d
> > > iscuss.
> > > To view this discussion on the web visit
> > > https://groups.google.com/d/msgid/googlefonts-discuss/CAEozd0yg2S
> > > eYO00d9Mq7pETmPQMFJ8n30B6sg-fpbhofBqW9Ng%40mail.gmail.com.
> > >
> > > For more options, visit https://groups.google.com/d/optout.
> >
> >
>
> -------------------------------------------------------------------
> -----------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Inkscape-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: [googlefonts-discuss] Re: Variable Fonts support in Inkscape

Felipe Sanches-2
Quick update:

Regarding Variable fonts in Inkscape:

I had a meeting with Tav on IRC yesterday in the morning and I did
improve the code on the CSS attribute side (code is now pushed to
inkscape git master branch). We also discussed whether to call
FreeType directly or via a future bridge API not yet provided by
Pango. And Tav believes the proper way to do it would be by adding
such API on Pango. Tav mentioned that something similar happend in the
past with an API for accessing opentype font variation features being
added to pango upon Tav's request and he suggested I take a look at
its implementation and possibly submit a patch to pango myself.

2017-06-21 10:06 GMT-03:00 Tavmjong Bah <[hidden email]>:

>
> Hi Felipe,
>
> Sorry to miss you on IRC. I'm in the CEST time zone (UTC+2) and am
> normally around between 9AM to 9PM (off and on).
>
> I am probably the person that knows the text code the best... which is
> a bit scary.
>
> If Pango/HarfBuzz handles the variable font stuff then it shouldn't be
> too hard to get rendering working. You can have a look at how the
> OpenType stuff works, especially the 'getFontFeatureString() in
> style.cpp and Layout-TNG-Compute.cpp.
>
> Tav
>
> On Wed, 2017-06-21 at 00:00 -0300, Felipe Sanches wrote:
>> I've hit a roadblock / mental exhaustion from dealing with (banging
>> my
>> head against) the Inkscape codebase, so I think it is very much wiser
>> to switch gears at the moment and do some FontBakery work again for a
>> while. And possibly get back to Inkscape later for a fresh restart.
>> I'll take a look now at what's pending on the issue tracker for
>> FontBakery that may be safe to work on regardless of Lasse's upcoming
>> PR.
>>
>> Last week I should have met with Tav on a chat channel (possibly IRC)
>> but we ended up not being able to arrange a good time for that yet.
>> So
>> I'm still going to get some feedback/advice from him at some point in
>> the future.
>>
>> ScislaC (Josh Andler) on Inkscape IRC told me that not much people
>> touched the text-handling code in the past decade and that Tav is
>> probably the person who best knows it nowadays. So talking to him
>> will
>> probably be very good. I don't want to continue digging deeper in
>> that
>> code before talking to him, for instance.
>>
>> I sketched a bit of each portion of the code that we need: (a) CSS
>> attribute parsing, (b) some GTK dialog/widgets and (c) some freetype
>> API calls for rendering the variable fonts. What I still lack is a
>> broader overview on how all of this stitches together coherently.
>>
>> The concept is not much complicated. Read coordinate values from the
>> SVG file (as CSS attribute values), populate the UI of a dialog with
>> sliders, and then use that info when creating font instances. Then
>> use
>> those values also to setup the appropriate freetype API calls. But
>> the
>> devil is in the details. Among this, there's a whole labyrinth of
>> code
>> for CSS and text handling...
>>
>> Felipe Sanches
>>
>>
>> 2017-06-13 9:37 GMT-03:00 Felipe Sanches <[hidden email]>:
>> > Cool!
>> >
>> > I would just avoid using the term "palette" because I recently
>> > learned that
>> > the term "font-palette" is used in the CSS spec for something else
>> > (relating
>> > to color palettes in coloured font faces).
>> >
>> > As can be seen here:
>> > https://drafts.csswg.org/css-fonts-4/#font-palette-prop
>> >
>> > 2017-06-13 9:20 GMT-03:00 Dave Crossland <[hidden email]>:
>> > >
>> > >
>> > >
>> > > On Jun 5, 2017 4:57 PM, "Felipe Sanches" <[hidden email]>
>> > > wrote:
>> > >
>> > > There may be occasions when the user may want to modify the
>> > > design-space
>> > > coordinates of a given variable font globally on the document. Do
>> > > you think
>> > > this is a valid concern / valid usage scenario ?
>> > >
>> > >
>> > > I think you should postpone this for now and consider it a future
>> > > possible
>> > > milestone.
>> > >
>> > > In that case, a variable font instance may behave like a shared
>> > > resource,
>> > > analogous to a shared gradient or filter-effect. But then we
>> > > would need to
>> > > make this an explicit user-choice, perhaps by providing a
>> > > dedicated dialog
>> > > for setting up such shared font resources. Like a "palette of
>> > > font
>> > > instances". Does it make sense ?
>> > >
>> > >
>> > > Yes, more sophisticated typesetting environments have "character
>> > > styles"
>> > > and "paragraph styles" which are such palettes and afaik inkscape
>> > > doesn't
>> > > have a UI for that.
>> > >
>> > > Cheers
>> > > Dave
>> > >
>> > > --
>> > > You received this message because you are subscribed to the
>> > > Google Groups
>> > > "Google Fonts Discussions" group.
>> > > To unsubscribe from this group and stop receiving emails from it,
>> > > send an
>> > > email to [hidden email].
>> > > To post to this group, send email to googlefonts-discuss@googlegr
>> > > oups.com.
>> > > Visit this group at https://groups.google.com/group/googlefonts-d
>> > > iscuss.
>> > > To view this discussion on the web visit
>> > > https://groups.google.com/d/msgid/googlefonts-discuss/CAEozd0yg2S
>> > > eYO00d9Mq7pETmPQMFJ8n30B6sg-fpbhofBqW9Ng%40mail.gmail.com.
>> > >
>> > > For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>>
>> -------------------------------------------------------------------
>> -----------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Inkscape-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel