334588 - fontname and fontsize in printing.properties used inconsistently for header and footer

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Eli Friedman]

Steps to reproduce (in en-US and most other locales):

1. Start/restart your browser.
1. Set your default serif font to something very distinctive.
2. Print any document.
3. Print again.

Expected results:
Header and footer stay the same.

Actual results:
The header and footer use Times the first time you print, and your default serif font the second time you print.

This would be relatively easy to fix; the issue is that the localization is loaded after the font is set.  However, I doubt having it localized is actually useful.  Apparently, at least a few of the localizations have translated the word serif, which almost certainly does not give a useful result.

A list of how CVS locales' fontname differed from the en-US "serif" (the rest had fontname=serif, the default serif font):
de: Uppercased
fi: Translated
he: Translated
hy-AM: Not sure
ko: Not sure
mk: Not sure
pl: Translated
ru: Not sure
sq: Uppercased
zh-CN: Not sure

No locale changed the default font size of 10.

From this, I don't think having a localizable header/footer font is useful.

Not sure who to CC.

Comment 1

[Eli Friedman]

Attachment: Patch

The other possibility would be to keep this localizable and add a localization note to choose useful defaults.  I'm not sure that would be much of an improvement.

Comment 2

[Eli Friedman]

Checked in.

Comment 3

[Bryan]

does this apply to branch and if so can we get it approved for branch if it's safe?

Comment 4

[Eli Friedman]

First off, it's traditional to CC yourself when you comment on a bug, so you know when people respond in the bug.

(In reply to comment #3)
> does this apply to branch and if so can we get it approved for branch if it's
> safe?

I think it would apply to the branch, although I'm not sure.  I'd wait a few days before nominating it.

I'm curious, why do you think this is important to get on the branch?  Apparently, nobody's noticed this bug for years.  I only knew this bug existed from looking at the code.  Why is this important enough to get into a stable branch for products currently in beta?

Comment 5

[Bryan]

(In reply to comment #4)
> First off, it's traditional to CC yourself when you comment on a bug, so you
> know when people respond in the bug.

There is no need for me to add myself to the CC field as I'm "watching" this component (I get emails for every bug commented or added to this component).

> I think it would apply to the branch, although I'm not sure.  I'd wait a few
> days before nominating it.
> 
> I'm curious, why do you think this is important to get on the branch? 
> Apparently, nobody's noticed this bug for years.  I only knew this bug existed
> from looking at the code.  Why is this important enough to get into a stable
> branch for products currently in beta?

I actually noticed this sometime ago but didn't think much about it.  This functionality is broken or at least doesn't work as it should.  If there is now a fix and it resolves the issue then why not apply it the branch?  Just makes sense to me.

~B

Comment 6

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #5)
> I actually noticed this sometime ago but didn't think much about it.  This
> functionality is broken or at least doesn't work as it should.  If there is now
> a fix and it resolves the issue then why not apply it the branch?  Just makes
> sense to me.

The "why not" is usually "because it may introduce a regression". Changes for the branch must be evaluated for risk vs. reward, especially at this stage in the release cycle (just before beta 2). I'm not the best person to evaluate the regression risk of this patch, but I think it's pretty clear that the reward isn't that great, from a user perspective.