Infrastructure

biggest difference is that the site no longer uses google's font service that hands out css explicitly targeted for the calling browser, but instead uses a combined css that has the various format variants for the browser to pick a favorite.

Needs detailed information about browser version/OS and if possible also diagnostic info (using web-developer console or similar) to see what font-variant is chosen (i.e. what file format of the font))

Florian Effenberger wrote:
"we now receive some error reports that the font is broken, for IE and Firefox at least, on Windows. People claim it loads properly, and then some characters disappear. Anyone can confirm?"

I confirm.
The LibreOffice.org pages load properly, but then some characters disappear and text is hardly readable/ unreadable.

Christian Lohmaier wrote:
http://forums.mozillazine.org/viewtopic.php?f=9&t=2846339
"that was posted to the qa-list has the info that the adblock plus extension might trigger it (it's better with that disabled)"

I tested with IE9 with all add-ons disabled (among which Adblock Plus for IE).
The result was the same:
The LibreOffice.org pages load properly, but then some characters disappear.

Re-posted from LibreOffice website mailing list:

June 20, 2014, by Spiff:
http://nabble.documentfoundation.org/LibreOffice-website-does-not-display-all-characters-tp4113027.html

The LibreOffice.org website does not display all characters, for some reason.
Some texts are unreadable.
See:
http://www.imgdumper.nl/uploads7/53a459f8db594/53a459f8c6d2f-LibreOffice.png
http://www.imgdumper.nl/uploads7/53a45a094c8e5/53a45a0942c9f-LibreOffice-Fresh.png
http://www.imgdumper.nl/uploads7/53a45a18769c3/53a45a186e8d7-LibreOffice-Portable.png
http://www.imgdumper.nl/uploads7/53a45a27864c7/53a45a277e7cb-LibreOffice-Notes.png
System:
Windows Vista x86 SP2 with IE9.

It is the same issue that was reported here for Firefox:
http://nabble.documentfoundation.org/Bug-80041-New-Other-Website-is-not-displaying-all-characters-under-Firefox-29-01-td4112411.html
And probably it is the same issue that was reported here for Firefox and Pale Moon, although I cannot tell for sure because I can't see what was in the included image:
http://nabble.documentfoundation.org/LibreOffice-Homepage-display-is-missing-characters-UNCLASSIFIED-td4112590.html

July 05, 2014, Charles-H. Schulz replied:
http://nabble.documentfoundation.org/LibreOffice-website-does-not-display-all-characters-tp4113027p4114722.html
We did try to reproduce this and we were not able to do this.

July 05, 2014, Spiff replied:
http://nabble.documentfoundation.org/LibreOffice-website-does-not-display-all-characters-tp4113027p4114724.html
That's odd.
Did you use Windows Vista with IE9 as I mentioned?
N.B. I ruled out influence of any add-ons, testing it with IE9 with add-ons disabled. Same result.

July 05, 2014, Charles-H. Schulz replied:
http://nabble.documentfoundation.org/LibreOffice-website-does-not-display-all-characters-tp4113027p4114741.html
I have no idea where it comes from.
http://redmine.documentfoundation.org > projects > infrastructure > open a new issue for this website.

And that's where I noticed this Bug #412 tread and took the liberty to Edit/ reply.

Best regards,
Spiff

without knowing what the actual reason is, finding a solution is tricky... But finding a reproducible scenario is what turns out to be quite hard...

Also a run on browsershots (a website that loads a site in tons of browsers) didn't show the problem (at least not in the time it was allotted to test).

So yes, it is a font-related problem obviously, and we provide a font to use to display the site. And the browsers in general is capable of understanding the css properly. Just that some unknown combination of browser and plugins and operating system settings/third party stuff they start to fail.

Believe me, I tried hard to reproduce, but so far still didn't manage to get it to render erratically. I'm starting to suspect a combination of graphic driver/hardware acceleration to be the problem (as I do all my testing in virtual machines)... Of course that doesn't make it any easier...

It is not an encoding problem (the characters can be copied and pasted just fine), and it is not the problem of the font-format in general (as otherwise it wouldn't be able to display anything at all..)

What might help if affected people using firefox would open the web developer tools (the "inspector") and go to the "fonts" tab in the right-hand subwindow and click "see all the fonts used in the page" in that window.

The interesting info is: What font-names are listed, what format is used (woff or eot or ttf..) and what source-line is displayed in the css-excerpt.

As a test, I have replaced the Lato font with the googleapis version again.

Please report back if that solves the issue for you or not. (note that I'm only interested in feedback from people that previously experienced the problem, telling "it works" from people for whom it worked before doesn't help :-))

Replacing the Lato font with the googleapis version again solves the issue for me, with Vista + IE9.
All libreoffice.org pages are now as they should be, with no characters disappearing.

The difference in http://libreoffice.org/ and http://newdesign.libreoffice.org/ is evident.
As I reported, replacing the Lato font with the googleapis version again solved the issue for me, with Vista + IE9.
The newdesign page has the same issue as were mentioned before.

As I am using IE and not Firefox, I cannot use the font-inspector diagnostics as mentioned for Firefox in comment #9.
I use Internet Explorer's diagnostic options via F12.
I can't find any option for font-inspector diagnostics as was mentioned for Firefox. Does anyone know if such option is available in IE?
What I do find:
There is no difference in CSS.
No errors are found in http://newdesign.libreoffice.org/ Script.
But oddly, http://libreoffice.org/ Script debugging mentions this:

CSS3111: font-face has encountered an unknown error.
http://themes.googleusercontent.com/static/fonts/lato/v7/2HG_tEPiQ4Z6795cGfdivPY6323mHUZFJMgTvxaG2iE.eot
CSS3111: font-face has encountered an unknown error.
http://themes.googleusercontent.com/static/fonts/lato/v7/zLhfkPOm_5ykmdm-wXaiuw.eot
CSS3111: @ font-face has encountered an unknown error.
http://themes.googleusercontent.com/static/fonts/lato/v7/KlmP_Vc2zOZBldw8AfXD5g.eot

Strange, as not libreoffice.org but newdesign.libreoffice.org is the one wih the issue of characters disappearing.

P.S.
For some reason I don't receive any Redmine e-mail notifications, even though e-mail notifications is enabled for my Redmine account.
That's quite inconvenient.
Is there a way to fix that?

added you explicitly as watcher of this bug - if you then still don't receive a mail, then your notification settings are wrong..

And there should be differences in css - fonts.googleapis only includes one single fileformat-variant, while the lato2 one uses css that contains multiple variants, where the browser has to pick the one it understands best.

http://www.libreoffice.org/themes/libreofficenew/css/Lato2.css for example has multiple variants, with different "format('format-identifier)" lines

css usually works the way that when a browser doesn't understand a property, it will ignore it.

I also didn't find a font-inspector for IE9 in the bultin webtools - maybe it is available as an external plugin

Thanks for adding me as watcher of this bug.
I received the e-mail notification this time.

Regarding the CSS and other diagnostic options via Internet Explorer F12 (Developer Tools), I'll have another look at it later today, to see if I can find anything useful.
First I have some other things to do.

I had another look at Internet Explorer Developer Tools for http://www.libreoffice.org/ and http://newdesign.libreoffice.org/
CSS details are very limited and the same for both versions.
I guess it may be as you said - CSS works the way that when a browser doesn't understand a property, it will ignore it.
I haven't found anything else that might be of interest.
If anyone might know what to look for, where to look, and/or what to test using IE9's Developer Tools, and could tell me so, then I'll have a look at it in a couple of days.
And I hope you can contact Firefox users who reported the issue and ask them to use the developer tools and investigate the fonts and other things of interest.

Best regards,
Spiff

Setting up a test site as proposed by Florian in reply #17 seems a good idea to me.
Is such a test site set up, yet?
If so, what is it's URL?

Planned by the end of this week, Cloph will notify the website list then :)

Over the past weeks, I have been checking the website list (http://nabble.documentfoundation.org/Website-f1644957.html) for Cloph's notification for the test site, but I haven't seen any notification of such.
I suppose setting up the test site took longer than expected, or did I miss the notification, somehow?

Thank you, Florian.
Regarding the test site, ah, so that's http://newdesign.libreoffice.org/
Christian mentioned that site three months ago, in reply #12.
I tested, and reported in my replies #13 and #16.
But I don't think that http://newdesign.libreoffice.org/ site is what you (Florian) meant in your reply #17.
Nevertheless, in case someone has feedback, they can do as you suggested, add it to this ticket or send it to the website list.

newdesign.libreoffice.org is the one - it uses the new (extended character coverage) version of the font - so if anyone can create a virtual machine that shows the problem with that site to reproduce, then I might be able to do something about it - but other than that, it's impossible to fix for me..

Could the demo site with Lato v2 be available again for testing purposes? I would like to ask some people about it, but would need a site to show.
Here are also four possible solutions, that might work (or not), I do not know if they were tested with Lato v1 and/or v2 yet:

1) One of the solutions might be to add the "!important" tag:
http://www.wastedpotential.com/solved-google-web-fonts-not-displaying-on-some-macs/

2) The other possibility is to at least try the squirrelfont (or other similar service) with the same font to see if the API is to blame:
http://webdesignandsuch.com/fix-fonts-that-dont-work-with-google-font-api-in-internet-explorer-or-chrome-with-font-face/

3) If Lato v1 already includes Slavic characters maybe only requiring all the subsets (adding "&subset=latin,latin-ext" at the end of font href) would solve the issue:
http://stackoverflow.com/questions/4495098/google-fonts-css-latin-question

4) Some web programmers use Javascript to make the display of webfonts more bullet-proof:
http://sixrevisions.com/css/font-face-web-fonts-issues/

Hope that testing one of these solutions makes a difference.

Thanks,
Martin

On this page:
https://www.google.com/fonts/specimen/Lato
it is shown how to include extended Latin characters from Lato font.

Was this the change that the demo (aka Lato v2) site used or was that achieved by actually using another version of Lato font?

My proposal is to change one line in www.libreoffice.org headers from:
<link href='//fonts.googleapis.com/css?family=Lato:100,300,400,700,900,300italic,400italic' rel='stylesheet' type='text/css'>
to:
<link href='//fonts.googleapis.com/css?family=Lato:100,300,400,700,900,300italic,400italic&subset=latin,latin-ext' rel='stylesheet' type='text/css'>

This way the 蚞ȊŽ characters which are obviously already a part of this font become usable and will not be replaced by Helvetica etc.

Also, why does the link of href in LO site start with //, the Google Fonts API site has this example:
<link href='http://fonts.googleapis.com/css?family=Lato&subset=latin,latin-ext&#039; rel='stylesheet' type='text/css'>

https://www.google.com/fonts/specimen/Lato doesn't list č

nevertheless I changed it to include the additional subset specifier.

And links start so they will adapt to https and http correctly. https://en.wikipedia.org/wiki/Wikipedia:Protocol-relative_URL

And no, this is not the change that is used at http://newdesign.libreoffice.org - there manual (i.e. not loaded from google) css is used to load Lato2 font (that unfortunately is not avialble on googlefonts) - but with thatt some browsers just don't render the letters

The bug after 3 years still here (checked on Win7 -- FF 55.0.3, Chrome 60.0.3112.113; same browsers on Ubuntu 16.04.3).
I just checked the "Lato" font locally (v. 2.0 downloaded from http://www.latofonts.com/ ). It has all necessary symbols at least for Lithuanian alphabet.
So the cause is that Google APIs didn't updates "Lato" font to the latest version. Does exists a way to place the v. 2.0 of "Lato" font on the libreoffice.org website server directly?

I've taken a look at this and have some findings. The Google Fonts API (which the website uses) does not contain Lato 2.0. In fact, the team at Google has decided to not update it for now due to some problems with the font (more information at https://github.com/google/fonts/issues/6).

Thus, it is not good to compare the current font to what is www.latofonts.com.

Thus, possible courses of action here, as I see it, are,

1. adding the setting to the CMS (that could be done through a Dataextension maybe) (what #2368 suggested) to enable the fallback font on demand

2. self-host Lato 2.0 (but care should be taken care because of the bugs mentioned by the Google team)

3. add some sort of code in the layout to check if the language is known to have problems and if yes, then use the fallback (similar to 1 but is fixed in the code)

4. ignore the issue for now until more news is possible.

Sorry for jumping into this just wanted to help a very little bit.

Sorry for jumping into this just wanted to help a very little bit.

No need to be sorry, rather the contrary - thanks so much for this
insight, that's indeed good findings!

We could switch to a newer Google Font with increased character coverage, such as Encode Sans, Nunito Sans, Archivo, Source Sans Pro, etc.

I'm chasing this up on the website@ list now with the SL and LT communities, in case there has been any progress.

I tried on mac OS 10.13, with Firefox 57, Chrome 62 and Safari - looks
wrong on all these. Maybe browsershots.org helps finding the pattern?

Florian Effenberger wrote:

I tried on mac OS 10.13, with Firefox 57, Chrome 62 and Safari - looks
wrong on all these. Maybe browsershots.org helps finding the pattern?

Thanks for the info Florian. To keep track of all feedback, here's some more from the website list. Dennis Roczek:

confirmed, look wired here.

Windows 10 with following browser

• Firefox 57 (clean profile, no extensions!)
• Edge
• Vivaldi (based on newest Chrome engine)
• IE11

And Antanas Budriūnas:

OS: Ubuntu 16.04.3 LTS x86_64,
Browsers: Google Chrome 62.0.3202.94, Firefox Quantum 57.0.1

So it's a tricky problem to pin down. Will investigate further though.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Just a thought. maybe it is not a browser problem but loading something
from a resource? Is the content all HTTPS? (mixed content!) I have https
at some places activated.

What about ublock blocking fonts? (at least activated in my vivaldi).

On 04.12.2017 11:30, The Document Foundation Redmine wrote:

Dennis Roczek wrote:

Just a thought. maybe it is not a browser problem but loading something
from a resource? Is the content all HTTPS? (mixed content!)

I'm not sure how to check that I'm afraid (I'm not a web developer so this is all quite new to me!). Do you know of any way to check in Firefox, for instance?

What about ublock blocking fonts? (at least activated in my vivaldi).

I've tried with and without uBlock, and it doesn't seem to make a difference.

At least on Linux, disabling Lato fixes the problem -- see lato_vs_system_font.png attached to this ticket.

I could try changing to a different font such as Encode Sans, but it looks like this involves lots of changes to the CSS and I'm reticent to do it on the live site. http://newdesign.libreoffice.org doesn't appear to be working either but I'll chase it up with infra and maybe we can test it there...

Meanwhile, I'm using our "newdesign" server for testing, and I've self-hosted Lato2. In addition, I've pasted bits of text from the Slovene and Lithuanian websites, which were broken before, into the "Free Office Suite" and "Fun Project" sections when you scroll down:

http://newdesign.libreoffice.org

With the most recent Lato2, this appears to work for me in Linux, whereas with the Lato2 from Google it looks odd as we previously discussed. So self-hosting might be the fix. Asking on the website@ list now for feedback.

OK, so with self-hosted Lato2 (the newest version) it seems to fix the Lithuanian issue. Antanas Budriūnas says:

I see no glitches, all characters are now displayed 100 percent correctly.

Good news, but need to do more checks before making the switch.

Updated the main site to self-hosted Lato2, using the following steps:

• Added file themes/libreofficenew/css/Lato2-new.css
• Added fonts in themes/libreofficenew/fonts/Lato2-new/
• Edited /themes/libreofficenew/templates/Page.ss - commented out the remote fonts.googleapis.com link on line 19, and added this on line 22:

<link href="/themes/libreofficenew/css/Lato2-new.css" rel='stylesheet' type='text/css' />

This appears to have fixed the problems with Lithuanian and Slovene, but I'll post on the website@ list and keep an eye out for other feedback.

Do things work as expected now, did we get positive feedback? Then we could close this ticket :-)
Thanks for chasing this!