1936253 - some font rendering broken after font update

Status: RESOLVED DUPLICATE of bug 1941820

(Core :: Layout: Text and Fonts, defect, P3)

Description

[sasc]

Attachment: different font rendering in FF133 and FF134

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:133.0) Gecko/20100101 Firefox/133.0

Steps to reproduce:

OS: Endeavour (arch based)

Today there was an update for the tft-opensans package. After installing, font rendering changed and is actually inconsistent with the developer edition's rendition of some text.

For example, go to https://demo.freshrss.org/ and observe that almost all text is displayed in italic font. Open the same page with the latest developer edition and observe the difference. Also see the attached screenshot.

I was not quite sure, wether this is an issue with packaging, with the font itself, the webpage or with Firefox - but given that FF134 as well as Chrome do not see any changes after the update, I thought this might be the place to report.

Actual results:

Fonts render in italic which did not so before

Expected results:

Fonts should not be rendered in italic (developer edition behaviour). Also Chrom(ium) renders these fonts non-italic.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: Text' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Lee Salzman [:lsalzman]]

Jonathan, is this some type of font selection issue?

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Could you run mozregression to figure out what caused the 133 to 134 behavior change?

$ mozregression --bad 133 --good 134 --find-fix -a <your-url>

should work.

Assuming this is somewhat configuration specific so triaging as S3 (I also use Arch and I don't see this on 133).

Comment 4

[sasc]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

Could you run mozregression to figure out what caused the 133 to 134 behavior change?

$ mozregression --bad 133 --good 134 --find-fix -a <your-url>

should work.

Assuming this is somewhat configuration specific so triaging as S3 (I also use Arch and I don't see this on 133).

Done. :)

First good revision: 030412276e15ccc3c1893524e87b3b1b822e91fa
Last bad revision: cbd6a4e86db48aef29684602041908cb2debef2f

Pushlog

Comment 5

[Emilio Cobos Álvarez (:emilio)]

It's not a regression but a fix. I think given that fix it's likely that the font includes some broken metadata like the one discussed in that bug.

Comment 6

[sasc]

News - now the latest developer version also shows the reported behaviour, same as 134.0.1.

I reran mozregression --bad 134 --good 132 -a https://demo.freshrss.org

and that resulted in

Comment 7

[sasc]

(In reply to sasc from comment #6)

News - now the latest developer version also shows the reported behaviour, same as 134.0.1.

I reran mozregression --bad 134 --good 132 -a https://demo.freshrss.org

and that resulted in

Last good revision: cbd6a4e86db48aef29684602041908cb2debef2f
First bad revision: 030412276e15ccc3c1893524e87b3b1b822e91fa
Pushlog

which somehow complete contradicts my earlier mozregression-run.

Anyway - the issue persists, is not present in 134 and 135, too and it seems like https://bugzilla.mozilla.org/show_bug.cgi?id=1941820 is related. I do not see the issue which is reported there, though. Presumably because of different fonts.

Sorry for the messy report - seems like I cannot edit my comment directly above.