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.



On 1 February 2018 at 22:10, Justin Obara <obara.jus...@gmail.com> wrote:

> I’ve filed a FLUID-6244
> <https://issues.fluidproject.org/browse/FLUID-6244> to address this, at
> least as an initial step, by adding a grunt build process to the
> Infusion-Icons <https://github.com/fluid-project/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 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 <obara.jus...@gmail.com> wrote:
>> Recently we’ve been working on a couple of tasks to add new preferences
>> to the prefs framework: letter-spacing (FLUID-6204
>> <https://issues.fluidproject.org/browse/FLUID-6204>) and syllabification
>> (FLUID-6240 <https://issues.fluidproject.org/browse/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 <https://github.com/fluid-project/infusion-icons>) from
>> which we could run a build step to generate the icon font. (see:
>> FLUID-5555 <https://issues.fluidproject.org/browse/FLUID-5555>).
>> 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
>> <https://wiki.fluidproject.org/display/fluid/Standard+workflow+in+maintaining+and+creating+icon+fonts>
>>  and Infusion Icons Visual Style Guide
>> <https://wiki.fluidproject.org/display/fluid/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
>> <https://github.com/sapegin/grunt-webfont> and it’s node engine based
>> off of svgicons2svgfont <https://github.com/nfroidure/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 <https://fontforge.github.io/en-US/>  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
>> because the fontforge dependency was missing. (NOTE: It seems that if
>> fontforge is missing it will fall back to using the node engine).
>> Barring any suggestions for ensuring that fontforge is installed, I think
>> we should continue to manually updated the icon font(s) used in Infusion.
>> However, we should start generating the font using the Infusion-Icons repo
>> and grunt-webfont with the fontforge engine. We may also want to commit a 
>> codepoints
>> file <https://github.com/sapegin/grunt-webfont#codepointsfile> to the
>> Infusion repo alongside the generated font to help keep track of which
>> icons are included and what codepoint refers to them. I believe this will
>> help make the icon fonts easier to generate, consistent and stable. It’s
>> not quite as convenient as having it part of the Infusion build, but it
>> should mean that the icons are always valid.
>> Let us know what you think.
>> Thanks
>> Justin
>> _______________________________________________________
>> fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
>> To unsubscribe, change settings or access archives,
>> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
fluid-work mailing list - fluid-work@lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

Reply via email to