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 <obara.jus...@gmail.com> wrote: > I’ve filed a PR <https://github.com/fluid-project/infusion-icons/pull/4> 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 <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
