Re: Icon font building

[Justin Obara]

Thanks Tony,

That was really quick. I’ll take a look at it.

Thanks
Justin


On February 8, 2018 at 5:14:57 AM, Tony Atkins (t...@raisingthefloor.org)
wrote:

Hi, All:

As I didn't want to block Justin's work, I went ahead and added the Vagrant
configuration and docs this morning.  See my pull against his pull here:

https://github.com/jobara/infusion-icons/pull/1

Cheers,


Tony

On 7 February 2018 at 15:35, Justin Obara  wrote:

> I’ve filed a PR  for
> my current build scripts. It would be great if we could include the VM
> setup in this PR, but if not, we can file a separate JIRA to add it later.
>
> Thanks
> Justin
>
>
> On February 5, 2018 at 11:33:46 AM, Justin Obara (obara.jus...@gmail.com)
> wrote:
>
> Hi Tony,
>
> I have the grunt tasks working for generating a the icon fonts. You can
> either generate a font with all the icons or a custom font based off a
> supplied config file.
>
> https://github.com/jobara/infusion-icons/tree/FLUID-6244
>
> Thanks again for the help with the VM setup.
>
> Thanks
> Justin
>
>
> On February 2, 2018 at 7:18:24 AM, Justin Obara (obara.jus...@gmail.com)
> wrote:
>
> Hi Tony,
>
> Thanks for your help. I’ll get the grunt script setup. It will be some
> extra work to get things to work with an external config file, but I’m
> hoping not much extra. Anyways I’ll check in with you once that’s in place.
>
>
> We can add the font building to our CI, know that the build succeeded, and
> have the fonts available as an artefact associated with a successful build.
>
>
> I’m not sure if that would work in the process I described, but I guess we
> can touch base on it once there’s something in place to work from.
>
> Thanks
> Justin
>
> On February 2, 2018 at 4:57:26 AM, Tony Atkins (t...@raisingthefloor.org)
> wrote:
>
> Hi, Justin:
>
> It's incredibly trivial to set up a Vagrantfile with Alfredo's new
> plugin.  Let me know once you have the grunt script setup and I can submit
> a pull against your branch or otherwise assist.
>
> Cheers,
>
>
> Tony
>
> On 1 February 2018 at 22:10, Justin Obara  wrote:
>
>> I’ve filed a FLUID-6244
>>  to address this, at
>> least as an initial step, by adding a grunt build process to the
>> Infusion-Icons  repo.
>>
>> Here's the suggestion for the new process:
>>
>>- In Infusion-Icons add a grunt task to generate an icon font that
>>includes all of the icons
>>- In Infusion-Icons add a grunt task for building a custom icon font
>>based on a config file
>>-
>>   - The config file will be versioned in the project's repo (e.g.
>>   Infusion), and include the paths to the SVGs to use, and their 
>> codepoints
>>   - The config file would be able to contain any configuration that
>>   is valid for grunt-webfont task
>>- After an icon font is generated, the implementor will need to
>>manually place it in the specific project repo
>>
>> Example Config:
>> {
>> src: [
>> "svg/contrast.svg",
>> "svg/reset-undo-arrow.svg",
>> "svg/line-space-expanded.svg",
>> "svg/line-space-condensed.svg",
>> "svg/line-space.svg"
>> ],
>> options: {
>> font: "custom-icons",
>> codepoints: {
>> "contrast": 0xE005,
>> "reset-undo-arrow": 0xE008,
>> "line-space-expanded": 0xE009,
>> "line-space-condensed": 0xE00a,
>> "line-space": 0xE00b
>> }
>> }
>> }
>>
>> I understand this isn’t the most elegant solution, but I think it will at
>> least, in the short term, provide a workable solution that still preserves
>> the configuration for generating the icon font and make it easier to see
>> which icons are included at which codepoints. As we have time in the
>> future, I think we should look for ways to improve this workflow, including
>> adding the VM option to remove the need to manually install fontforge and
>> ttfautohint.
>>
>> Thanks
>> Justin
>>
>> On February 1, 2018 at 12:50:44 PM, Justin Obara (obara.jus...@gmail.com)
>> wrote:
>>
>>
>> Hi Tony,
>>
>> I was thinking about this more today and I’m not sure it will work in the
>> same repo. Basically the issue is that it uses a grunt task to do the font
>> generation while relying on fontforge and ttfautohint installed separately
>> on the machine. The issue of course is the npm install required and
>> bridging across a host and vm. We use grunt for other build tasks that have
>> been run on the host machine and probably won’t want to force anyone to
>> have to use the vm.
>>
>> I’m wondering now if we just add something to the Infusion-Icons repo for
>> building fonts. We could require that fontforge and ttfautohint are
>> installed, or setup a vm option. Any thoughts?
>>
>> Thanks
>> Justin
>>
>> On January 26, 2018 at 8:13:45 AM, Justin 

Re: Icon font building

[Justin Obara]

Hi Tony,

I have the grunt tasks working for generating a the icon fonts. You can
either generate a font with all the icons or a custom font based off a
supplied config file.

https://github.com/jobara/infusion-icons/tree/FLUID-6244

Thanks again for the help with the VM setup.

Thanks
Justin


On February 2, 2018 at 7:18:24 AM, Justin Obara (obara.jus...@gmail.com)
wrote:

Hi Tony,

Thanks for your help. I’ll get the grunt script setup. It will be some
extra work to get things to work with an external config file, but I’m
hoping not much extra. Anyways I’ll check in with you once that’s in place.


We can add the font building to our CI, know that the build succeeded, and
have the fonts available as an artefact associated with a successful build.


I’m not sure if that would work in the process I described, but I guess we
can touch base on it once there’s something in place to work from.

Thanks
Justin

On February 2, 2018 at 4:57:26 AM, Tony Atkins (t...@raisingthefloor.org)
wrote:

Hi, Justin:

It's incredibly trivial to set up a Vagrantfile with Alfredo's new plugin.
Let me know once you have the grunt script setup and I can submit a pull
against your branch or otherwise assist.

Cheers,


Tony

On 1 February 2018 at 22:10, Justin Obara  wrote:

> I’ve filed a FLUID-6244
>  to address this, at
> least as an initial step, by adding a grunt build process to the
> Infusion-Icons  repo.
>
> Here's the suggestion for the new process:
>
>- In Infusion-Icons add a grunt task to generate an icon font that
>includes all of the icons
>- In Infusion-Icons add a grunt task for building a custom icon font
>based on a config file
>-
>   - The config file will be versioned in the project's repo (e.g.
>   Infusion), and include the paths to the SVGs to use, and their 
> codepoints
>   - The config file would be able to contain any configuration that
>   is valid for grunt-webfont task
>- After an icon font is generated, the implementor will need to
>manually place it in the specific project repo
>
> Example Config:
> {
> src: [
> "svg/contrast.svg",
> "svg/reset-undo-arrow.svg",
> "svg/line-space-expanded.svg",
> "svg/line-space-condensed.svg",
> "svg/line-space.svg"
> ],
> options: {
> font: "custom-icons",
> codepoints: {
> "contrast": 0xE005,
> "reset-undo-arrow": 0xE008,
> "line-space-expanded": 0xE009,
> "line-space-condensed": 0xE00a,
> "line-space": 0xE00b
> }
> }
> }
>
> I understand this isn’t the most elegant solution, but I think it will at
> least, in the short term, provide a workable solution that still preserves
> the configuration for generating the icon font and make it easier to see
> which icons are included at which codepoints. As we have time in the
> future, I think we should look for ways to improve this workflow, including
> adding the VM option to remove the need to manually install fontforge and
> ttfautohint.
>
> Thanks
> Justin
>
> On February 1, 2018 at 12:50:44 PM, Justin Obara (obara.jus...@gmail.com)
> wrote:
>
>
> Hi Tony,
>
> I was thinking about this more today and I’m not sure it will work in the
> same repo. Basically the issue is that it uses a grunt task to do the font
> generation while relying on fontforge and ttfautohint installed separately
> on the machine. The issue of course is the npm install required and
> bridging across a host and vm. We use grunt for other build tasks that have
> been run on the host machine and probably won’t want to force anyone to
> have to use the vm.
>
> I’m wondering now if we just add something to the Infusion-Icons repo for
> building fonts. We could require that fontforge and ttfautohint are
> installed, or setup a vm option. Any thoughts?
>
> Thanks
> Justin
>
> On January 26, 2018 at 8:13:45 AM, Justin Obara (obara.jus...@gmail.com)
> wrote:
>
> Hi Tony,
>
> Thanks for this suggestion. The VM approach seems like a good option. I
> don’t think it will be something that we run that frequently, so the
> overhead of the VM shouldn’t be too much to worry about.
>
> Regarding location, I think I’d prefer having it in the main repo. I feel
> like it will be easier to update the icons if the build process is
> colocated, and it should be fine to version the icons alongside Infusion. I
> suppose if we break Infusion out into a monorepo we could explore
> separating the icons into their own package(s) (there will likely be
> separate fonts for each component that uses icons in order to keep file
> sizes to a minimum). I’m open to other ideas though.
>
> Thanks
> Justin
>
>
> On January 26, 2018 at 3:38:36 AM, Tony Atkins (t...@raisingthefloor.org)
> wrote:
>
> Thanks for the writeup, Justin.
>
> I think the obvious solution here is to use our 

Re: Icon font building

[Justin Obara]

Hi Tony,

Thanks for your help. I’ll get the grunt script setup. It will be some
extra work to get things to work with an external config file, but I’m
hoping not much extra. Anyways I’ll check in with you once that’s in place.


We can add the font building to our CI, know that the build succeeded, and
have the fonts available as an artefact associated with a successful build.


I’m not sure if that would work in the process I described, but I guess we
can touch base on it once there’s something in place to work from.

Thanks
Justin

On February 2, 2018 at 4:57:26 AM, Tony Atkins (t...@raisingthefloor.org)
wrote:

Hi, Justin:

It's incredibly trivial to set up a Vagrantfile with Alfredo's new plugin.
Let me know once you have the grunt script setup and I can submit a pull
against your branch or otherwise assist.

Cheers,


Tony

On 1 February 2018 at 22:10, Justin Obara  wrote:

> I’ve filed a FLUID-6244
>  to address this, at
> least as an initial step, by adding a grunt build process to the
> Infusion-Icons  repo.
>
> Here's the suggestion for the new process:
>
>- In Infusion-Icons add a grunt task to generate an icon font that
>includes all of the icons
>- In Infusion-Icons add a grunt task for building a custom icon font
>based on a config file
>-
>   - The config file will be versioned in the project's repo (e.g.
>   Infusion), and include the paths to the SVGs to use, and their 
> codepoints
>   - The config file would be able to contain any configuration that
>   is valid for grunt-webfont task
>- After an icon font is generated, the implementor will need to
>manually place it in the specific project repo
>
> Example Config:
> {
> src: [
> "svg/contrast.svg",
> "svg/reset-undo-arrow.svg",
> "svg/line-space-expanded.svg",
> "svg/line-space-condensed.svg",
> "svg/line-space.svg"
> ],
> options: {
> font: "custom-icons",
> codepoints: {
> "contrast": 0xE005,
> "reset-undo-arrow": 0xE008,
> "line-space-expanded": 0xE009,
> "line-space-condensed": 0xE00a,
> "line-space": 0xE00b
> }
> }
> }
>
> I understand this isn’t the most elegant solution, but I think it will at
> least, in the short term, provide a workable solution that still preserves
> the configuration for generating the icon font and make it easier to see
> which icons are included at which codepoints. As we have time in the
> future, I think we should look for ways to improve this workflow, including
> adding the VM option to remove the need to manually install fontforge and
> ttfautohint.
>
> Thanks
> Justin
>
> On February 1, 2018 at 12:50:44 PM, Justin Obara (obara.jus...@gmail.com)
> wrote:
>
>
> Hi Tony,
>
> I was thinking about this more today and I’m not sure it will work in the
> same repo. Basically the issue is that it uses a grunt task to do the font
> generation while relying on fontforge and ttfautohint installed separately
> on the machine. The issue of course is the npm install required and
> bridging across a host and vm. We use grunt for other build tasks that have
> been run on the host machine and probably won’t want to force anyone to
> have to use the vm.
>
> I’m wondering now if we just add something to the Infusion-Icons repo for
> building fonts. We could require that fontforge and ttfautohint are
> installed, or setup a vm option. Any thoughts?
>
> Thanks
> Justin
>
> On January 26, 2018 at 8:13:45 AM, Justin Obara (obara.jus...@gmail.com)
> wrote:
>
> Hi Tony,
>
> Thanks for this suggestion. The VM approach seems like a good option. I
> don’t think it will be something that we run that frequently, so the
> overhead of the VM shouldn’t be too much to worry about.
>
> Regarding location, I think I’d prefer having it in the main repo. I feel
> like it will be easier to update the icons if the build process is
> colocated, and it should be fine to version the icons alongside Infusion. I
> suppose if we break Infusion out into a monorepo we could explore
> separating the icons into their own package(s) (there will likely be
> separate fonts for each component that uses icons in order to keep file
> sizes to a minimum). I’m open to other ideas though.
>
> Thanks
> Justin
>
>
> On January 26, 2018 at 3:38:36 AM, Tony Atkins (t...@raisingthefloor.org)
> wrote:
>
> Thanks for the writeup, Justin.
>
> I think the obvious solution here is to use our existing VM infrastructure
> to make it easy to build the font regardless of the host platform.  There
> are fontforge packages for Linux, we just need to have a Vagrant VM that
> installs fontforge as part of its setup steps.  I'd suggest using the Linux
> VM because it's more amenable to using vagrant ssh commands as part of npm
> script definitions.  We could add a 

Re: Icon font building

[Tony Atkins]

Hi, Justin:

It's incredibly trivial to set up a Vagrantfile with Alfredo's new plugin.
Let me know once you have the grunt script setup and I can submit a pull
against your branch or otherwise assist.

Cheers,


Tony

On 1 February 2018 at 22:10, Justin Obara  wrote:

> I’ve filed a FLUID-6244
>  to address this, at
> least as an initial step, by adding a grunt build process to the
> Infusion-Icons  repo.
>
> Here's the suggestion for the new process:
>
>- In Infusion-Icons add a grunt task to generate an icon font that
>includes all of the icons
>- In Infusion-Icons add a grunt task for building a custom icon font
>based on a config file
>   - The config file will be versioned in the project's repo (e.g.
>   Infusion), and include the paths to the SVGs to use, and their 
> codepoints
>   - The config file would be able to contain any configuration that
>   is valid for grunt-webfont task
>- After an icon font is generated, the implementor will need to
>manually place it in the specific project repo
>
> Example Config:
> {
> src: [
> "svg/contrast.svg",
> "svg/reset-undo-arrow.svg",
> "svg/line-space-expanded.svg",
> "svg/line-space-condensed.svg",
> "svg/line-space.svg"
> ],
> options: {
> font: "custom-icons",
> codepoints: {
> "contrast": 0xE005,
> "reset-undo-arrow": 0xE008,
> "line-space-expanded": 0xE009,
> "line-space-condensed": 0xE00a,
> "line-space": 0xE00b
> }
> }
> }
>
> I understand this isn’t the most elegant solution, but I think it will at
> least, in the short term, provide a workable solution that still preserves
> the configuration for generating the icon font and make it easier to see
> which icons are included at which codepoints. As we have time in the
> future, I think we should look for ways to improve this workflow, including
> adding the VM option to remove the need to manually install fontforge and
> ttfautohint.
>
> Thanks
> Justin
>
> On February 1, 2018 at 12:50:44 PM, Justin Obara (obara.jus...@gmail.com)
> wrote:
>
>
> Hi Tony,
>
> I was thinking about this more today and I’m not sure it will work in the
> same repo. Basically the issue is that it uses a grunt task to do the font
> generation while relying on fontforge and ttfautohint installed separately
> on the machine. The issue of course is the npm install required and
> bridging across a host and vm. We use grunt for other build tasks that have
> been run on the host machine and probably won’t want to force anyone to
> have to use the vm.
>
> I’m wondering now if we just add something to the Infusion-Icons repo for
> building fonts. We could require that fontforge and ttfautohint are
> installed, or setup a vm option. Any thoughts?
>
> Thanks
> Justin
>
> On January 26, 2018 at 8:13:45 AM, Justin Obara (obara.jus...@gmail.com)
> wrote:
>
> Hi Tony,
>
> Thanks for this suggestion. The VM approach seems like a good option. I
> don’t think it will be something that we run that frequently, so the
> overhead of the VM shouldn’t be too much to worry about.
>
> Regarding location, I think I’d prefer having it in the main repo. I feel
> like it will be easier to update the icons if the build process is
> colocated, and it should be fine to version the icons alongside Infusion. I
> suppose if we break Infusion out into a monorepo we could explore
> separating the icons into their own package(s) (there will likely be
> separate fonts for each component that uses icons in order to keep file
> sizes to a minimum). I’m open to other ideas though.
>
> Thanks
> Justin
>
>
> On January 26, 2018 at 3:38:36 AM, Tony Atkins (t...@raisingthefloor.org)
> wrote:
>
> Thanks for the writeup, Justin.
>
> I think the obvious solution here is to use our existing VM infrastructure
> to make it easy to build the font regardless of the host platform.  There
> are fontforge packages for Linux, we just need to have a Vagrant VM that
> installs fontforge as part of its setup steps.  I'd suggest using the Linux
> VM because it's more amenable to using vagrant ssh commands as part of npm
> script definitions.  We could add a vagrant:buildFont script or the like
> that runs the build within the VM.   Just like coverage reports and other
> artefacts created from within the VM, the final icon font would be
> available from the host machine at the end of the build process.
>
> I can't imagine us writing a tool to verify whether an icon looks
> reasonable or not, so manual intervention is still required whatever we
> do.  To assist in the review, we could create a page that displays all
> icons, ideally with something like the UIOptions component so we can test
> high contrast.  I would imagine that whomever is running the build would
> review this, and then 

Re: Icon font building

[Tony Atkins]

Hi, Justin.

I'm definitely a bigger fan of making it possible to use the VM for this,
even if some of us choose to install the libraries and run the commands on
their machine.  We can express (in the VM configuration) the dependencies
that are required in a clear way that can be tested.  There should
definitely be something in the docs as well, but IMO the testing part is
key.  We can add the font building to our CI, know that the build
succeeded, and have the fonts available as an artefact associated with a
successful build.

I'd suggest setting up an npm script that we can run locally, and another
that runs that script in the VM, as we've done with our "test:vagrant" and
other script definitions.

Cheers,


Tony

On 1 February 2018 at 18:50, Justin Obara  wrote:

>
> Hi Tony,
>
> I was thinking about this more today and I’m not sure it will work in the
> same repo. Basically the issue is that it uses a grunt task to do the font
> generation while relying on fontforge and ttfautohint installed separately
> on the machine. The issue of course is the npm install required and
> bridging across a host and vm. We use grunt for other build tasks that have
> been run on the host machine and probably won’t want to force anyone to
> have to use the vm.
>
> I’m wondering now if we just add something to the Infusion-Icons repo for
> building fonts. We could require that fontforge and ttfautohint are
> installed, or setup a vm option. Any thoughts?
>
> Thanks
> Justin
>
>
> On January 26, 2018 at 8:13:45 AM, Justin Obara (obara.jus...@gmail.com)
> wrote:
>
> Hi Tony,
>
> Thanks for this suggestion. The VM approach seems like a good option. I
> don’t think it will be something that we run that frequently, so the
> overhead of the VM shouldn’t be too much to worry about.
>
> Regarding location, I think I’d prefer having it in the main repo. I feel
> like it will be easier to update the icons if the build process is
> colocated, and it should be fine to version the icons alongside Infusion. I
> suppose if we break Infusion out into a monorepo we could explore
> separating the icons into their own package(s) (there will likely be
> separate fonts for each component that uses icons in order to keep file
> sizes to a minimum). I’m open to other ideas though.
>
> Thanks
> Justin
>
>
> On January 26, 2018 at 3:38:36 AM, Tony Atkins (t...@raisingthefloor.org)
> wrote:
>
> Thanks for the writeup, Justin.
>
> I think the obvious solution here is to use our existing VM infrastructure
> to make it easy to build the font regardless of the host platform.  There
> are fontforge packages for Linux, we just need to have a Vagrant VM that
> installs fontforge as part of its setup steps.  I'd suggest using the Linux
> VM because it's more amenable to using vagrant ssh commands as part of npm
> script definitions.  We could add a vagrant:buildFont script or the like
> that runs the build within the VM.   Just like coverage reports and other
> artefacts created from within the VM, the final icon font would be
> available from the host machine at the end of the build process.
>
> I can't imagine us writing a tool to verify whether an icon looks
> reasonable or not, so manual intervention is still required whatever we
> do.  To assist in the review, we could create a page that displays all
> icons, ideally with something like the UIOptions component so we can test
> high contrast.  I would imagine that whomever is running the build would
> review this, and then we have a decision about how to publish it.
>
> To me, it makes sense to move the icon font to a small repo (or small part
> of a monorepo) and then manually publish a versioned release of the icon
> font.  As we don't want to get in the business of managing constant
> releases, I'd imagine us making use of fluid-publish, and creating dev
> releases to test with work in progress.
>
> I understand this might be a bit of a reach, I could also see us setting
> up additional commands that run against the linux VM we use to test
> infusion itself and leaving it in the main repo.  In that scenario, the
> font can be updated by any commit, and the version is simply pinned to
> whichever dev or standard release other packages pull in.
>
> Happy to discuss here or in a future meeting, if we agreed that the VM
> approach is worth doing somewhere, and then define "somewhere", I'd imagine
> this being a pretty easy thing to set up.
>
> Cheers,
>
>
> Tony
>
>
>
> On 25 January 2018 at 20:35, Justin Obara  wrote:
>
>> Recently we’ve been working on a couple of tasks to add new preferences
>> to the prefs framework: letter-spacing (FLUID-6204
>> ) and syllabification
>> (FLUID-6240 ). For
>> both of these new preferences we’ll need to provide a new icon for the
>> adjuster.
>>
>> Icons for the preferences framework are added using an icon font. The

Re: Icon font building

[Justin Obara]

Hi Tony,

I was thinking about this more today and I’m not sure it will work in the
same repo. Basically the issue is that it uses a grunt task to do the font
generation while relying on fontforge and ttfautohint installed separately
on the machine. The issue of course is the npm install required and
bridging across a host and vm. We use grunt for other build tasks that have
been run on the host machine and probably won’t want to force anyone to
have to use the vm.

I’m wondering now if we just add something to the Infusion-Icons repo for
building fonts. We could require that fontforge and ttfautohint are
installed, or setup a vm option. Any thoughts?

Thanks
Justin

On January 26, 2018 at 8:13:45 AM, Justin Obara (obara.jus...@gmail.com)
wrote:

Hi Tony,

Thanks for this suggestion. The VM approach seems like a good option. I
don’t think it will be something that we run that frequently, so the
overhead of the VM shouldn’t be too much to worry about.

Regarding location, I think I’d prefer having it in the main repo. I feel
like it will be easier to update the icons if the build process is
colocated, and it should be fine to version the icons alongside Infusion. I
suppose if we break Infusion out into a monorepo we could explore
separating the icons into their own package(s) (there will likely be
separate fonts for each component that uses icons in order to keep file
sizes to a minimum). I’m open to other ideas though.

Thanks
Justin


On January 26, 2018 at 3:38:36 AM, Tony Atkins (t...@raisingthefloor.org)
wrote:

Thanks for the writeup, Justin.

I think the obvious solution here is to use our existing VM infrastructure
to make it easy to build the font regardless of the host platform.  There
are fontforge packages for Linux, we just need to have a Vagrant VM that
installs fontforge as part of its setup steps.  I'd suggest using the Linux
VM because it's more amenable to using vagrant ssh commands as part of npm
script definitions.  We could add a vagrant:buildFont script or the like
that runs the build within the VM.   Just like coverage reports and other
artefacts created from within the VM, the final icon font would be
available from the host machine at the end of the build process.

I can't imagine us writing a tool to verify whether an icon looks
reasonable or not, so manual intervention is still required whatever we
do.  To assist in the review, we could create a page that displays all
icons, ideally with something like the UIOptions component so we can test
high contrast.  I would imagine that whomever is running the build would
review this, and then we have a decision about how to publish it.

To me, it makes sense to move the icon font to a small repo (or small part
of a monorepo) and then manually publish a versioned release of the icon
font.  As we don't want to get in the business of managing constant
releases, I'd imagine us making use of fluid-publish, and creating dev
releases to test with work in progress.

I understand this might be a bit of a reach, I could also see us setting up
additional commands that run against the linux VM we use to test infusion
itself and leaving it in the main repo.  In that scenario, the font can be
updated by any commit, and the version is simply pinned to whichever dev or
standard release other packages pull in.

Happy to discuss here or in a future meeting, if we agreed that the VM
approach is worth doing somewhere, and then define "somewhere", I'd imagine
this being a pretty easy thing to set up.

Cheers,


Tony



On 25 January 2018 at 20:35, Justin Obara  wrote:

> Recently we’ve been working on a couple of tasks to add new preferences to
> the prefs framework: letter-spacing (FLUID-6204
> ) and syllabification (
> FLUID-6240 ). For both
> of these new preferences we’ll need to provide a new icon for the adjuster.
>
> Icons for the preferences framework are added using an icon font. The
> current icon font was pre-generated with the required icons included.
> However, we found that it was hard to maintain when new icons are needed.
> To that end, work was done to implement a repository of icons (
> Infusion-Icons ) from
> which we could run a build step to generate the icon font. (see:
> FLUID- ).
>
> As part of my recent work, I’ve been looking at incorporating a build step
> in Infusion to generate the icon fonts using icons from the Infusion-Icons
> repo. We’re taking this opportunity to update and unify the icons as well,
> and along the way have learned a lot about how icons should be constructed.
> (see: Standard workflow in maintaining and creating icon fonts
> 
>  and Infusion Icons Visual Style Guide
> 

Re: Icon font building

[Justin Obara]

Hi Tony,

Thanks for this suggestion. The VM approach seems like a good option. I
don’t think it will be something that we run that frequently, so the
overhead of the VM shouldn’t be too much to worry about.

Regarding location, I think I’d prefer having it in the main repo. I feel
like it will be easier to update the icons if the build process is
colocated, and it should be fine to version the icons alongside Infusion. I
suppose if we break Infusion out into a monorepo we could explore
separating the icons into their own package(s) (there will likely be
separate fonts for each component that uses icons in order to keep file
sizes to a minimum). I’m open to other ideas though.

Thanks
Justin


On January 26, 2018 at 3:38:36 AM, Tony Atkins (t...@raisingthefloor.org)
wrote:

Thanks for the writeup, Justin.

I think the obvious solution here is to use our existing VM infrastructure
to make it easy to build the font regardless of the host platform.  There
are fontforge packages for Linux, we just need to have a Vagrant VM that
installs fontforge as part of its setup steps.  I'd suggest using the Linux
VM because it's more amenable to using vagrant ssh commands as part of npm
script definitions.  We could add a vagrant:buildFont script or the like
that runs the build within the VM.   Just like coverage reports and other
artefacts created from within the VM, the final icon font would be
available from the host machine at the end of the build process.

I can't imagine us writing a tool to verify whether an icon looks
reasonable or not, so manual intervention is still required whatever we
do.  To assist in the review, we could create a page that displays all
icons, ideally with something like the UIOptions component so we can test
high contrast.  I would imagine that whomever is running the build would
review this, and then we have a decision about how to publish it.

To me, it makes sense to move the icon font to a small repo (or small part
of a monorepo) and then manually publish a versioned release of the icon
font.  As we don't want to get in the business of managing constant
releases, I'd imagine us making use of fluid-publish, and creating dev
releases to test with work in progress.

I understand this might be a bit of a reach, I could also see us setting up
additional commands that run against the linux VM we use to test infusion
itself and leaving it in the main repo.  In that scenario, the font can be
updated by any commit, and the version is simply pinned to whichever dev or
standard release other packages pull in.

Happy to discuss here or in a future meeting, if we agreed that the VM
approach is worth doing somewhere, and then define "somewhere", I'd imagine
this being a pretty easy thing to set up.

Cheers,


Tony



On 25 January 2018 at 20:35, Justin Obara  wrote:

> Recently we’ve been working on a couple of tasks to add new preferences to
> the prefs framework: letter-spacing (FLUID-6204
> ) and syllabification (
> FLUID-6240 ). For both
> of these new preferences we’ll need to provide a new icon for the adjuster.
>
> Icons for the preferences framework are added using an icon font. The
> current icon font was pre-generated with the required icons included.
> However, we found that it was hard to maintain when new icons are needed.
> To that end, work was done to implement a repository of icons (
> Infusion-Icons ) from
> which we could run a build step to generate the icon font. (see:
> FLUID- ).
>
> As part of my recent work, I’ve been looking at incorporating a build step
> in Infusion to generate the icon fonts using icons from the Infusion-Icons
> repo. We’re taking this opportunity to update and unify the icons as well,
> and along the way have learned a lot about how icons should be constructed.
> (see: Standard workflow in maintaining and creating icon fonts
> 
>  and Infusion Icons Visual Style Guide
> ).
> However, it seems that the build system we were hoping for lacks the
> robustness required for it to be a build step in Infusion.
>
> The original hope and expectation was to use grunt-webfont
>  and it’s node engine based off
> of svgicons2svgfont  to
> generate the icon font. With much research and trial and error we have yet
> to be able to produce an acceptable icon font, in particular when complex
> glyphs are required some of the glyphs become distorted and jumbled. See
> “icon output.png” attached for an example of a distorted icon. To
> experiment with this directly you can run the 

Re: Icon font building

[Tony Atkins]

Thanks for the writeup, Justin.

I think the obvious solution here is to use our existing VM infrastructure
to make it easy to build the font regardless of the host platform.  There
are fontforge packages for Linux, we just need to have a Vagrant VM that
installs fontforge as part of its setup steps.  I'd suggest using the Linux
VM because it's more amenable to using vagrant ssh commands as part of npm
script definitions.  We could add a vagrant:buildFont script or the like
that runs the build within the VM.   Just like coverage reports and other
artefacts created from within the VM, the final icon font would be
available from the host machine at the end of the build process.

I can't imagine us writing a tool to verify whether an icon looks
reasonable or not, so manual intervention is still required whatever we
do.  To assist in the review, we could create a page that displays all
icons, ideally with something like the UIOptions component so we can test
high contrast.  I would imagine that whomever is running the build would
review this, and then we have a decision about how to publish it.

To me, it makes sense to move the icon font to a small repo (or small part
of a monorepo) and then manually publish a versioned release of the icon
font.  As we don't want to get in the business of managing constant
releases, I'd imagine us making use of fluid-publish, and creating dev
releases to test with work in progress.

I understand this might be a bit of a reach, I could also see us setting up
additional commands that run against the linux VM we use to test infusion
itself and leaving it in the main repo.  In that scenario, the font can be
updated by any commit, and the version is simply pinned to whichever dev or
standard release other packages pull in.

Happy to discuss here or in a future meeting, if we agreed that the VM
approach is worth doing somewhere, and then define "somewhere", I'd imagine
this being a pretty easy thing to set up.

Cheers,


Tony



On 25 January 2018 at 20:35, Justin Obara  wrote:

> Recently we’ve been working on a couple of tasks to add new preferences to
> the prefs framework: letter-spacing (FLUID-6204
> ) and syllabification (
> FLUID-6240 ). For both
> of these new preferences we’ll need to provide a new icon for the adjuster.
>
> Icons for the preferences framework are added using an icon font. The
> current icon font was pre-generated with the required icons included.
> However, we found that it was hard to maintain when new icons are needed.
> To that end, work was done to implement a repository of icons (
> Infusion-Icons ) from
> which we could run a build step to generate the icon font. (see:
> FLUID- ).
>
> As part of my recent work, I’ve been looking at incorporating a build step
> in Infusion to generate the icon fonts using icons from the Infusion-Icons
> repo. We’re taking this opportunity to update and unify the icons as well,
> and along the way have learned a lot about how icons should be constructed.
> (see: Standard workflow in maintaining and creating icon fonts
> 
>  and Infusion Icons Visual Style Guide
> ).
> However, it seems that the build system we were hoping for lacks the
> robustness required for it to be a build step in Infusion.
>
> The original hope and expectation was to use grunt-webfont
>  and it’s node engine based off
> of svgicons2svgfont  to
> generate the icon font. With much research and trial and error we have yet
> to be able to produce an acceptable icon font, in particular when complex
> glyphs are required some of the glyphs become distorted and jumbled. See
> “icon output.png” attached for an example of a distorted icon. To
> experiment with this directly you can run the attached “size.svg” through
> http://nfroidure.github.io/svgiconfont/ with “Font height” set to 512.
>
> Fortunately grunt-webfont provides the option to use an alternative
> engine, fontforge   In experimenting
> with our new icon set, I’ve found that fontforge actually produces a proper
> icon font. However, there is a trade off. Although fontforge is available
> for macOS, Linux, and Windows, it is a manual process to install it because
> it isn’t an NPM module. Unless there is a straightforward way to install
> the platform specific versions of fontforge as part of the "npm install"
> for Infusion, I don’t think it is safe to add font generation as a build
> step. It would be very unfortunate if the icons were broken in a release
>