Explain further please.

from ui_alchemy-rails.

Bundling is bad for several reason. See:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

And especially in this case, the split will be extremely easy.
In our case the best benefit will be easier maintenance. And smaller packages - the fonts hardly change ever. So every new release of converge-ui (or Katello or Aeolus) always ship payload of 1.2 MB always-same-data, which can reside in standalone package and be left untouched.

from ui_alchemy-rails.

Not trying to be difficult but I am not following you. Are you arguing that fonts should live in some separate git repository or that there needs to be a spec file specific to packaging up the fonts that ConvergeUI provides?

from ui_alchemy-rails.

Honestly - I do not care if it will be separate git repo or if it will be another directory here with own .spec file. Or subpackage of converge-ui.
The last one is easiest, the first probably cleanest.

from ui_alchemy-rails.

Why do we care about liberation. why are we packing or depending on it?
We aren't using any graphics rasterization library that depends on particular fonts right?

The only non symbolic font we should care about is overpass and that's not for upstream use anyway.

our css for fonts should be embarrassingly simple

/* all text */
body{font-family: sans, sans-serif; } /*if they have liberation  on rhel or fedora it will default */

/* headers, navigation and labels only */
h1,h2,h3,h4,h5,h6,label, nav, dt, th, thead {font-family: overpass, helvetica, "liberation sans", arial, sans-serif;} 

/*png, svg then symbolic icon fallbacks with modernizr */

.icon{background-image: url(symbols.png);background-image: url(symbols.svg); }
.webfont .icon:before{font-family:symbolic; background-image: none;}

Upstream, it will make sense to include ONLY our icon font because it will have been rendered specifically for our projects.

• With the commercial release we should care about packaging overpass only but not care about liberation as it is not dependent on our aesthetic or branding mandate. *and it's not exactly ascenders best work either * )

How do the openshift folks package overpass? do what they do.

Our fonts CSS should not have to change between versions because the cascading rules will fall back to fonts installed on the clients system.

TL;DR

• Include our icon font when we render it. it will be specific to us. ( we havent finalised this yet)
• Reference overpass as a standalone package and depend on it - hopefully one already exists
• Ignore liberation. if we ignore it long enough, it will go away. I'm not kidding. we'll support system defaults for common type and things will look much better as a result.

DO NOT go to the effort of bundling liberation or depending on the standalone packages.

These files should not be in our repo. (overpass might need to be included for branded mode debugging but if this causes any potential conflict for packaging we should relent and remove it)

from ui_alchemy-rails.

The reason we include Liberation is to have the same (or as close to same) experience across all browser and devices. If we rely on the Operating System to provide the font, we risk the lack of that font and thus rendering issues and a poor visual experience across all Operating Systems and browsers.

from ui_alchemy-rails.

This has been widely dismissed as a bad idea. (for body text)

You already know different operating systems have different 2d drawing API's and different browsers use different type layout engines on top of that. well it gets much worse when you throw @fontface in the mix for your main copy text because those small font mechanisms are pretty much flying blind.

Let's go through a list of things adding liberation wont fix for us.

it will not fix linebreaking

the difference in text layout engines means that some features are supported while others are ignored. Some are even faked.

EG: ligatures are supported, faked or ignored. meaning what was once two glyphs and vice versa - regardless of your font choice.

it will not make the site look the same (or similar)

the hinting engines on linux and windows make certain of that.
footprint of each character gets widely distorted meaning that the exact pixel width of an em cannot be relied upon.

It will not give us the same voice

Title text is large enough to have the characteristics of the font well represented. body text is so small that the hinting or layout engine is only going to harm the font. the operating system defaults are usually the best choice to go with as they are designed to work within all these quirks

from ui_alchemy-rails.

10-13px is munted. what was once liberation is now a mess at that size. freetype/cairo/pango/cleartype/quartz all have had their way with it and now you're looking at something that is insanely worse than the system defaults. and nothing like what liberation was intended to be.

The OS defaults (for the big two) are sacred territory for many using them. Ground that you don't mess with without a damned good reason. IMHO Liberation does not speak of our brand and even if it did; Liberation is not being displayed at a scale that a good enough representation is coming through to make it worthwhile.

Knowing that including liberation won't fix the technical issues like line breaking and string width. Do we really want to include it?

We already package liberation in Fedora and RHEL. Packagers will give us hell to pay if we duplicate those bytes out of laziness or uncertainty. our best bet is to throw it out for good reason.

Iconfont - yes
Overpass - maybe
Liberation - absolutely not

from ui_alchemy-rails.

andyfitz: we don't distribue open sans in fedora do we?
[10:57am] andyfitz: http://www.google.com/webfonts/specimen/Open+Sans
[10:59am] andyfitz: it has a few technical advantages. No upstream brand-sponsor, excellent CDN support, no default packaging in any of our products (so we can include it) .
[10:59am] andyfitz: and it was made by the same bloke who made liberation but on a good day
[11:00am] jrist: I can get behind open sans. and packaging it should be a breeze
[11:00am] andyfitz: jrist: and checkout those weights ;-) 400-700-500
[11:00am] andyfitz: lol
[11:00am] jrist: ha was just about to say that
[11:00am] jrist: the weights look fantastic (zoomed out a bunch)
[11:01am] jrist: I'm a big fan
[11:01am] andyfitz: thank censored ;-)

from ui_alchemy-rails.

So Jason was tired enough to agree that we should move away from liberation sans and more towards open sans

The reason?

• No packaging conflicts with TTF/OTF only packages. We can safely include the woff for good reason.
• No upstream brand-sponsor (no device or desktop that defaults to opensans )
• Excellent CDN support (we can toggle a flag to use the google CDN for upstream and toggle off for on-site )
• Has enough character at weights like 300 to hold its own besides the heavy weight overpass and overpass bold.
• We can throw out overpass for upstream and sub-in the heavy weights of open sans so that only on-site appears branded )

from ui_alchemy-rails.

We should absolutely be using Overpass in the upsteam. That is why it was created, so we have a Interstate like font which has license that allows use in the upstream and redistribution. Subbing out Overpass for Open Sans in the two different versions of the application will risk breaking the design unnecessarily. This is the same for switching between whatever system default and Open Sans depending on whether they are onsite would create a very inconsistent experience. We absolutely should be specifying a consistent typeface. One that will work on and off. This is why we use Lib Sans. Lib Sans is the metric equivalent to Arial. We can reference both typefaces as part of a stack and Open or Proprietary OS's have a consistent design.

Is there a reason we can not recommend Lib Sans as part of the default stack instead of packaging using @font-face? Also brand does specify Lib Sans and Overpass in the brand guide. Whether or not it is reinforced well is another thing all together.

http://design.lab.bos.redhat.com/w/images/b/bf/RH_BrandStandardsSupplement_FINAL_080212_LL_web.pdf

from ui_alchemy-rails.

@kybaker The Open Sans would replace Liberation Sans, not Overpass.

from ui_alchemy-rails.

"We can throw out overpass for upstream and sub-in the heavy weights of open sans so that only on-site appears branded )"

This is what I was responding to for the Overpass stuff. I still stand by my statements about Liberations Sans.

"This is the same for switching between whatever system default and Open Sans depending on whether they are onsite would create a very inconsistent experience. We absolutely should be specifying a consistent typeface. One that will work on and off premise. This is why we use Lib Sans. Lib Sans is the metric equivalent to Arial. We can reference both typefaces as part of a stack and Open or Proprietary OS's have a consistent design.

Is there a reason we can not recommend Lib Sans as part of the default stack instead of packaging using @font-face? Also brand does specify Lib Sans and Overpass in the brand guide. Whether or not it is reinforced well is another thing all together."

from ui_alchemy-rails.

Enough with the metric equivalent garbage. Don't make me take screenshots under freetype/cleartype/quartz all with different hinting settings. The difference in width will be around a factor of 20% for the same font.

This argument was useful when printing microsoft-made documents with layout engines made to duplicate microsoft functionality (openoffice) . But in the context of the web, dropping terms like "metric equivalent" is complete self-congratulating bullshit. That term means very little to world of web typography.

Back to the discussion:

Throwing liberation sans as part of the stack (assuming you mean font-family: "liberation sans", sans-serif; ) will break if a customer doesn't have it on their system. Yes we can include a css request for it rather than @fontface and support the relatively few folks who use RHEL and Fedora to administer their infrastructure. But the personality of the UI will change dramatically when they are on different systems . more-so than what we have now. - this is what jrist was on about and at first I didn't think it was worth it - but then I smelt the opportunity to kill liberation sans.

Also on that, need I say translations will alter string length too? Our UI needs to be adaptive to enormous and tiny strings for labels and copy. There is no escape. The technical benefits of liberation sans simply being 'predictable' for testing purposes are null and void here.

I argue (and I could be wrong) that liberation

• does not complement overpass at all,
• does not uniquely identify itself as a part of the Red Hat voice.
• does not hold stand-alone appeal

So why even mention it?

Packagers will have a problem with us binding Liberation Sans to our package because the truetype versions are already a part of other installed packages. (and its not small ) If there's one thing you can do to piss off a release maintainer, it's unnecessarily duplicate bytes via statically linking what should be your global assets.

However for the web; we need to at least use the .woff versions which arent included in the desktop packages so this gives us a little wiggle room from the potential platform packaging duplication but doesn't let us off the hook entirely.

Going upstream with overpass is a different discussion.
I take for granted that Overpass needs to exist in our commercial product.
The big benefit of Overpass is so we can include a branded representation of type without having to buy every single customer and every single staff member a license for interstate.

Now as for branding, Overpass looks like Red Hat and should part of our upstream message be to indicate that "this is a Red Hat sponsored property" Overpass is the only way to achieve that. I'm all for using Overpass for headings, labels and other short strings; pretty much wherever the representation of the type is large enough to show off the qualities that make overpass - overpass.

However, If we have the opportunity or mandate to differentiate upstream and our commercial product: Toggling off Overpass for upstream is the first thing that needs to change.

You wont see shadowman on CentOS and IMO (just my personal opinion) you shouldn't see overpass on Fedora/Katello/Conductor until you are looking at the commercial offering.

Dont come back with examples on openshift, Openshift is special (and allowed to use overpass) because we've open sourced an existing commercial offering (not the opposite way around) so the expectation set of customers is to see the open product still look like Red Hat made it.

For now, this conversation probably won't be resolved.

I suggest we keep Overpass for our tabs, buttons, headers and labels but we kill including liberation sans to appease our QA/Packaging/Release overlords.

Unless you can come back with type forensics on how the blocky and stale ascenders and descenders of liberation sans balance overpasses angles or how the irrefutably incompatible weights of the two are really re-enforcing some sort of contrast we have between body text and application chrome... We will kill liberation sans. The juice is not worth the squeeze.

We will kill it unless you find me one person doing design in our brand communications dept who can confidently declare that liberation sans is the Red Hat voice. You won't - no honest salesman can sell a lemon.
And dont pull out the brand book. Liberation sans was put in there to make sure that if all else fails (myriad) staff at least use a sans-serif typeface we know is installed on their system.

TL;DR

Liberation sans is ugly, off-brand and causes many technical and political issues. Its just plain stupid to consider coddling bad type into the future.

Overpass can stay so long as we want to say "Red Hat made this" I'm happy to maintain that position.

Open sans is more neutral, is appropriately licensed, looks less evil and has a huge variety of weights to chose from so we can select the thinner ones like 300 when we want to give Overpass more 'presence' — rather than just blindly upping or downing the font-size which seems to be the practice by the 10pixel bandits.

We will not blindly use Overpass for everything however.
Reading a long error message in Overpass will cause massive fatigue for no benefit.
There are too many flourishes in a title font like Overpass to put up with when reading at smaller scales and hopefully you're with me on that.

That's why Open Sans is my recommendation for copy.

• It gives us predictability in its qualities.
• Some nice weights that will let overpass shine
• The legibility to withstand longer dialogue.
• The same bloke made it but on a good day and without the "this needs to print like arial mandate"

from ui_alchemy-rails.

Wow that was a long rant.

You'd think liberation sans beat me when I was a child or something.
But no, Liberation Sans assaults our customers eyeballs for no good reason and I'd like to challenge it.
Keep it to printing old microsoft documents from libre office and away from the web

back to $subject;

We should keep the fonts part of our core packages because they are lightweight, do not frequently independently update and should be version-locked to our software.

Having them locked gives us the potential of making future alterations to glyphs like using the un-marked unicode range for our icon font rather than having a separate icon font. (saves on a http-request and makes the font truly ours \o/ )

having our fork of the fonts as a subpackage seems fine if our packagers are cool with it. keeping in mind without liberation we wont be looking at sizes as large as 2.*mb also keeping in mind converge-ui will likely be the only place that uses them

from ui_alchemy-rails.