Open Bug 1105606 Opened 10 years ago Updated 2 years ago

<pre></pre> area is rendered with non-monospaced font

Categories

(Core :: Graphics: Text, defect)

Product:
Core
Component:
Graphics: Text
Platform:
x86_64
FreeBSD
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: yuri, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; FreeBSD amd64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.65 Safari/537.36

Steps to reproduce:

go to https://phabricator.wikimedia.org/T76116


Actual results:

non-monospaced font is used for pre-area.

https://secure.phabricator.com/file/data/us53dfeadbqzcj77vmgu/PHID-FILE-go4c6qcnxwqdpqcr5qfp/ff30-phabricator-monospace.png


Expected results:

FF-33.0 says it uses DejaVu Sans system font for this pre area.
http://en.wikipedia.org/wiki/DejaVu_fonts says that only some DejaVu fonts are monospaced (ex. DejaVu Sans Mono), and the one used isn't monospaced.

FF-33.0 on FreeBSD-10.1
This might be system-specific, because I hear this doesn't happen on other OSes with FF-33.
Summary: <pre></pre> ares is rendered with non-monospaced font → <pre></pre> area is rendered with non-monospaced font
What is the monospace font pref set to in Preferences > Content (> fonts) > Advanced... ?
Component: Untriaged → Graphics: Text
Flags: needinfo?(yuri)
Product: Firefox → Core
It says "monospace" Siaze 12
Flags: needinfo?(yuri)
Also, selection for monospace font there offers non-monospace fonts too. This is wrong, I think, because if website requests monospace font, user can't override this.
(In reply to Yuri from comment #3)
> Also, selection for monospace font there offers non-monospace fonts too.
> This is wrong, I think, because if website requests monospace font, user
> can't override this.

So what is yours set to? A font actually called "monospace" ?
Flags: needinfo?(yuri)
It's normal for it to be set to "monospace" by default on *nix systems; fontconfig should then map this to a specific font.

Yuri, what does "fc-match monospace" return on your system?
$ fc-match monospace
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
Flags: needinfo?(yuri)
OK, that's the same as I have on an Ubuntu VM, but the problem does not occur here: the <pre> content is rendered in DejaVu Sans Mono as expected.
In inspector, if FF could also show how did it arrive at the font, this would automatically clarify this problem too.

So if I were you, I would implement such improvement, and this PR would be rendered trivial.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.