Some latin non-ASCII letters are inconsistent look with ASCII letters #73

embar- · 2015-10-28T15:38:30Z

When I open staged openSUSE site, I see bold Ą Č Ę Ė Į Š Ų Ū Ž letters in Lithuanian locale, while ASCII letters has non-bold style:

Maybe font not found?
I have installed quite a lot fonts:

zypper se -i font
Įkeliami saugyklų duomenys...
Skaitomi įdiegti paketai...

Similar bad look if I select Polish:

or Slovak:

coolo · 2015-10-29T07:01:09Z

looks fine on my TW. you can do the following:

coolo@thinkpad-X230-WLAN#cwar>fc-match sans-serif
DejaVuSans.ttf: "DejaVu Sans" "Book"
coolo@thinkpad-X230-WLAN#cwar>fc-match 'Source Sans Pro'
SourceSansPro-Regular.otf: "Source Sans Pro" "Regular"

I assume your sans-serif matches some bolder font

coolo · 2015-10-29T07:02:03Z

but I can see the problem with greek. 'Source Sans Pro' seems to be pretty limited ;(

coolo · 2015-10-29T11:36:18Z

http://blog.typekit.com/2014/07/09/source-sans-v2/ says the greek glyphs were only added in v2. That explains why it looks proper on TW.

embar- · 2015-10-29T12:36:51Z

fc-match sans-serif
arial.ttf: "Arial" "Normal"
fc-match 'Source Sans Pro'
arial.ttf: "Arial" "Normal"

embar- · 2015-10-29T12:44:37Z

After installing adobe-sourcesanspro-fonts it looks much better for Lithuanian:

fc-match 'Source Sans Pro'
SourceSansPro-Regular.otf: "Source Sans Pro" "Regular"

coolo · 2015-10-29T12:48:41Z

the fix for that is using @font-face normally

ghost · 2015-11-03T15:43:49Z

The site uses @font-face, it downloads some CSS from Google for that.

As you can see from the CSS, when the font is installed locally, the Google CSS gives preference to the locally installed font. The issues seem to be:

Google's version of Source Sans Pro is older than the packaged version (Greek is not among the characters that Google serves.)
Google's default configuration of the font does not include all the necessary characters and the font needs different subsetting options. (The (available) "Latin Extended" characters should fix the issues with Polish text.)

cf. https://www.google.com/fonts#ReviewPlace:refine/Collection:Source+Sans+Pro

yecril71pl · 2018-09-13T15:58:10Z

The instruction to load the font in the landing page is unsupported by the provider and the resulting format (TrueType) is unsupported by the browser.

ghost · 2018-09-14T10:49:08Z

@yecril71pl Which browser/OS combination are you speaking about? (Google will deliver different CSS to different browsers but this is generally pretty well tuned and usually works.)

yecril71pl · 2018-09-14T11:12:52Z

Microsoft Edge 42.17134.1.0
OS Name: Microsoft Windows 10 Pro
SEC7111: HTTPS security is compromised by http://fonts.gstatic.com/s/sourcesanspro/v11/6xK3dSBYKcSV-LCoeQqfX1RYOo3qOK7g.ttf
www.opensuse.org (1,1)
SEC7111: HTTPS security is compromised by http://fonts.gstatic.com/s/sourcesanspro/v11/6xKydSBYKcSV-LCoeQqfX1RYOo3ik4zwlxdr.ttf
www.opensuse.org (1,1)
CSS3119: No fonts available for @font-face rule
openSUSE.min.css (1,1100)

@font-face {
font-family: 'Source Sans Pro';
font-style: normal;
font-weight: 400;
src: local('Source Sans Pro Regular'),local('SourceSansPro-Regular'),url(http://fonts.gstatic.com/s/sourcesanspro/v11/6xK3dSBYKcSV-LCoeQqfX1RYOo3qOK7g.ttf) format('truetype')
}

The following page demonstrates that Google is right and we are wrong:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
><HTML LANG="pl" 
><META HTTP-EQUIV=CONTENT-TYPE CONTENT="TEXT/HTML; CHARSET=WINDOWS-1250" 
><TITLE >Sprawdzenie działania czcionki</TITLE 
><link href="https://fonts.googleapis.com/css?family=Source+Sans+Pro&amp;subset=latin-ext" 
rel="stylesheet" ><STYLE TYPE="TEXT/CSS" ><!--
h3 { FONT-FAMILY: 'Source Sans Pro', monospace }
--></STYLE 
><H1 >Sprawdzenie działania czcionki</H1 
><P 
>Czcionka <A HREF="https://fonts.google.com/specimen/Source+Sans+Pro" >Source Sans Pro</A > 
działa prawidłowo na <A HREF="#BQ-FONT-SAMPLE" >tej stronie</A >:
<BLOCKQUOTE ID=BQ-FONT-SAMPLE 
><h3 
class="text-center wow fadeInUp" lang="pl" 
style="visibility: visible; animation-name: fadeInUp;"
>Polecany przez twórców dla administratorów, programistów i użytkowników domowych.</h3
></BLOCKQUOTE 
><P 
>Natomiast na stronie 
<OBJECT TYPE="TEXT/HTML" DATA="https://www.opensuse.org/" WIDTH=400 HEIGHT=400 
><A HREF="https://www.opensuse.org/#opensuse-os" >openSUSE - Linux OS. 
Polecany przez twórców dla administratorów, programistów i użytkowników domowych.</A ></OBJECT > 
ładuje się ona 
<A HREF="https://github.com/openSUSE/landing-page/issues/73" HREFLANG="en-us" 
>nieprawidłowo</A >.

I have the following question: Why do we import font CSS at build time instead of at run time? This is unsupported by the provider.

Fix openSUSE#73 1. replace minify-css with clean-css 2. declare font face imports as css 3. prevent clean-css from expanding imports 4. request fonts with extended characters 5. update build instructions 6. add BUILD.CMD

ghost · 2018-09-14T16:19:04Z

I looked at your PR (and hence compared some of the delivered code with the source for the first time):

I think the issue is that Google's font CSS is @imported via Less and @import behaves differently in CSS and Less:

CSS @import is executed by the browser
Less @import is executed by the Less compiler (if you use less.js, that still runs in the browser; but we are using lessc locally and finally put up plain CSS)

Clearly, the author of the page expected CSS's behavior but got lessc's behavior.
This means, Google gets the request via HTTP and hence ships fonts via HTTP as well. Also, the HTTP request probably has a user agent string that is not recognized by Google, so Google delivers the lowest common denominator which is TTF fonts (as I said in the earlier comment, Google delivers different CSS based on the user agent string).

You could solve this issue by just using <link> tags in the HTML directly. Otherwise, you'd have to escape the @import rule, so lessc can't see it, I guess.

As a further explanation:

SEC7111: HTTPS security is compromised by http://fonts.gstatic.com/s/sourcesanspro/v11/6xK3dSBYKcSV-LCoeQqfX1RYOo3qOK7g.ttf
www.opensuse.org (1,1)

This error occurs because the fonts are unconditionally loaded via HTTP and not HTTPS. Just using // at the beginning of the URL would fix that.

TTF fonts should work pretty much everywhere, the only issue is that they have some size disadvantages. (After all, WOFF fonts are essentially compressed TTF fonts.) However, your browser blocks the TTF fonts because they are delivered via HTTP.

yecril71pl · 2018-09-15T12:52:21Z

@import (css) passes the import task to the browser but the effect was nuked by minify so I had to use clean instead.

yecril71pl mentioned this issue Sep 14, 2018

#73: require fonts with extended characters #141

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Some latin non-ASCII letters are inconsistent look with ASCII letters #73

Some latin non-ASCII letters are inconsistent look with ASCII letters #73

embar- commented Oct 28, 2015

coolo commented Oct 29, 2015

coolo commented Oct 29, 2015

coolo commented Oct 29, 2015

embar- commented Oct 29, 2015

embar- commented Oct 29, 2015

coolo commented Oct 29, 2015

ghost commented Nov 3, 2015

yecril71pl commented Sep 13, 2018

ghost commented Sep 14, 2018 •

edited by ghost

Loading

yecril71pl commented Sep 14, 2018 •

edited

Loading

ghost commented Sep 14, 2018

yecril71pl commented Sep 15, 2018

Some latin non-ASCII letters are inconsistent look with ASCII letters #73

Some latin non-ASCII letters are inconsistent look with ASCII letters #73

Comments

embar- commented Oct 28, 2015

coolo commented Oct 29, 2015

coolo commented Oct 29, 2015

coolo commented Oct 29, 2015

embar- commented Oct 29, 2015

embar- commented Oct 29, 2015

coolo commented Oct 29, 2015

ghost commented Nov 3, 2015

yecril71pl commented Sep 13, 2018

ghost commented Sep 14, 2018 • edited by ghost Loading

yecril71pl commented Sep 14, 2018 • edited Loading

ghost commented Sep 14, 2018

yecril71pl commented Sep 15, 2018

ghost commented Sep 14, 2018 •

edited by ghost

Loading

yecril71pl commented Sep 14, 2018 •

edited

Loading