Project

General

Profile

Bug #412

letters missing from website (some browsers don't display letters)

Added by Christian Lohmaier over 3 years ago. Updated 4 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
-
Target version:
Team - Pool
Start date:
Due date:
% Done:

0%

Estimated time:
Tags:
URL:

Description

the website font needs to be extended (or replaced for some locales) when coverage is not available at all.

was https://bugs.freedesktop.org/show_bug.cgi?id=78596

lithuanian_site_antanas.png (68.7 KB) lithuanian_site_antanas.png Mike Saunders, 2017-12-01 16:04
lithuanian_site_mike.png (210 KB) lithuanian_site_mike.png Mike Saunders, 2017-12-01 16:04
lato_vs_system_font.png (63.8 KB) lato_vs_system_font.png Mike Saunders, 2017-12-14 14:36
2152
2153
2165

Related issues

Has duplicate Infrastructure - Task #2368: NL website default font choice via CMSNew

History

#1 Updated by Florian Effenberger over 3 years ago

  • Due date set to 2014-05-23

#2 Updated by Christian Lohmaier over 3 years ago

  • % Done changed from 0 to 10

Lato font is available as v2 with extended glyph coverage, so at least for european langauges it should fit. Unfortunately not yet available via google's services, so have to manually add the css to the site..

#3 Updated by Christian Lohmaier over 3 years ago

  • Status changed from New to Closed
  • % Done changed from 10 to 100

added the Lato rev2 fonts to the site - it should cover all latin-style languages, Cyrillic and Greek.

#4 Updated by Florian Effenberger over 3 years ago

  • Status changed from Closed to In Progress

It might be related, because 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?

#5 Updated by Christian Lohmaier over 3 years ago

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

#6 Updated by Christian Lohmaier over 3 years ago

  • Subject changed from website font coverage lacks many characters to letters missing from website (some browsers don't display letters)

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)

#7 Updated by Spiff . over 3 years ago

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

#8 Updated by Charles-H. Schulz over 3 years ago

  • Priority changed from Normal to Urgent

Since Tuesday the 15th of July we now have reports coming from users of Firefox 30 on Windows stating the same problem (2-3 reports on Twitter).

Even if I cannot reproduce the problem myself, I do not understand the nature of the issue. Should we change the fonts? the encoding???

#9 Updated by Christian Lohmaier over 3 years ago

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.

#10 Updated by Christian Lohmaier over 3 years ago

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

#11 Updated by Spiff . over 3 years ago

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.

#12 Updated by Christian Lohmaier over 3 years ago

  • Status changed from In Progress to Feedback

setting status to feedback - as I gave up trying to reproduce/I'm out of ideas..

So if you want to help trying to find the root cause (or a way to reproduce) you can go to http://newdesign.libreoffice.org - that uses the extended character set version.

if you experience the issue, please post the difference in the font-related css as written in comment#9 (the font-inspector details)

#13 Updated by Spiff . over 3 years ago

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?

#14 Updated by Christian Lohmaier over 3 years ago

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

#15 Updated by Spiff . over 3 years ago

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.

#16 Updated by Spiff . over 3 years ago

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

#17 Updated by Florian Effenberger over 3 years ago

  • Due date changed from 2014-05-23 to 2014-08-10
  • Status changed from Feedback to In Progress

Status quo as I see it is the following:

With v1 of the current font, some languages work, but other languages (e.g. Slovenian) require v2. v2, however, is broken on certain systems, and so far it's still impossible to find a pattern here.

Proposal: Cloph sets up a test site by the end of next week with just some random font that people then can test and give feedback on. Note that this must NOT be the final font, it's merely a technical test, so please don't judge on the design. If it works out with another font, we then choose a final alternative font that could do.

#18 Updated by Spiff . over 3 years ago

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?

#19 Updated by Florian Effenberger over 3 years ago

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

#20 Updated by Spiff . over 3 years ago

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?

#21 Updated by Florian Effenberger about 3 years ago

  • Due date deleted (2014-08-10)
  • Assignee deleted (Christian Lohmaier)
  • Priority changed from Urgent to Normal
  • % Done changed from 100 to 0

De-assigning from Cloph, as feedback on the list is missing so far
For the records: The test site is http://newdesign.libreoffice.org

In case someone has feedback, please add it to this ticket or send it to the website list, and we then can always re-assign this ticket to Cloph

#22 Updated by Spiff . about 3 years ago

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.

#23 Updated by Christian Lohmaier about 3 years ago

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

#24 Updated by Martin Srebotnjak over 2 years ago

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

#25 Updated by Martin Srebotnjak over 2 years ago

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?

#26 Updated by Martin Srebotnjak over 2 years ago

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' rel='stylesheet' type='text/css'>

#27 Updated by Christian Lohmaier over 2 years ago

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

#28 Updated by Antanas Budriūnas 3 months ago

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?

#29 Updated by Antanas Budriūnas 3 months ago

  • Has duplicate Task #2368: NL website default font choice via CMS added

#30 Updated by Florian Effenberger 3 months ago

  • Assignee set to Mike Saunders
  • Target version set to Pool

I assumed this had been fixed long time ago, so not sure if this re-occured or was never fixed actually - if the latter, apologies.

Adding it to Mike's list of tasks - he's been doing good work on the website recently and might be able to help out
However, so short upfront the conference cycles are spare - is this super-urgent, or can we look into it in detail after LibOCon if we don't get a hand on it before?

#31 Updated by Jean Spiteri 3 months ago

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.

#32 Updated by Florian Effenberger 3 months ago

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!

#33 Updated by Adolfo Jayme Barrientos 3 months ago

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

#34 Updated by Mike Saunders 28 days ago

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

#35 Updated by Mike Saunders 17 days ago

OK, so I got a response from Antanas (from the Lithuanian community) on the website list.

Screenshot attached (lithuanian_site_antanas.png) is how he sees it - some characters look odd and are rendered in bold.

Another screenshot attached (lithuanian_site_mike.png) is from Firefox on my macOS box - all appears to be fine there.

So it may be some local rendering issue; investigating further now. If anyone watching the ticket has similar issues, please let me know!

#36 Updated by Florian Effenberger 14 days ago

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?

#37 Updated by Mike Saunders 14 days ago

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.

#38 Updated by Dennis Roczek 14 days ago

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

#39 Updated by Mike Saunders 4 days ago

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

#41 Updated by Mike Saunders 4 days ago

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.

#42 Updated by Mike Saunders 4 days ago

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.

Also available in: Atom PDF