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