531606 - Gecko 1.9.x (Firefox 3.x / Seamonkey 2) truncates print job name to only 30 characters

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Marcelo Bastos]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0

As detailed in this page: http://forums.mozillazine.org/viewtopic.php?f=9&t=736835 , newer versions of Mozilla products (Firefox 3 / Firefox 3.5 / Seamonkey 2), on printing, truncate print job names to 30 characters. Previous versions sent longer print job names (64 characters on FF 2).
This affects printing to PDF, where most utilities will use the job title as file name, and advanced printing utilities such as FinePrint, which use the print job name as page header.
This is annoying because frequently the useful part of the page title (excluding site name, etc.) is located beyond the 30-character point. 


Reproducible: Always

Steps to Reproduce:
1.Select a page with a long TITLE name.
2.Print (preferrably to a printer with a long queue, a stopped queue, or a virtual printer such as PDFcreator or FinePrint)
3.Check the print queue or the results from the virtual printer.
Actual Results:  
Job name is truncated, such as:
FF3 Truncating Print Web Pa...

Expected Results:  
Full job name, such as:
FF3 Truncating Print Web Page Job Title / Name • mozillaZine Forums

Comment 1

[Johannes Weiser]

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)

Problem persists as described above.

Comment 2

[El Loco]

Problem also easily repro'd with PrimoPDF, regardless of Windows OS (XP, Vista, Win7).

This isn't a sporadic bug - it occurs 100% of the time.  Time to change status to CONFIRMED!

Comment 3

[Pietro]

This is not exactly a bug, but it should be confirmed if it is the only way to get it solved. 

I have tried all freeware pdf printers around with Google Chrome and Firefox (pdfcreator, cutepdf, primopdf, dopdf etc...). Chrome allows full page title on filename, FF3 only allows some characters. FF2 behaved ok, too. 

Windows long filenames allow up to 255 characters, so this limitation in FF3 doesn´t make sense.

Comment 4

[El Loco]

Bump?? Confirm?

Comment 5

[RNicoletto]

Confirmed.

Comment 6

[Kyle Rickey]

Still occurs in 4.0 Beta 3.....

Comment 7

[Trevor Evans]

I can also confirm this occurs.

Comment 8

[Pietro]

yep. so firefox 4 beta 3 made me sad. :-(

Comment 9

[Sebastian]

yep. so firefox 4 beta _4_ made me also sad. :-(
The truncation is especially worse, when printing to pdf-driver, cause you have to manually edit the filename, even though the pagetitle is (in its full length) complete.

Comment 10

[Pietro]

firefox 4 beta 5 too (WHY ARE YOU IGNORING THIS?) >:-/

Comment 11

[Daniel Holbert [:dholbert]]

Please don't "bump" bugs or spam with biweekly "yup this affects another beta" comments.  This is a bug tracker, not a forum.  If someone takes the time to work on this issue, you'll see them post updates/patches here -- if you don't see that, then it shouldn't be any surprise that this issue remains.

Keep in mind that Mozilla is a free, open-source project, with limited resources.  Our bug tracker has plenty of issues like this that we'd love to address if/when we get the time, but we need to focus on the highest-priority bugs & features.  If this bug is important to you, you're free to work on it yourself (or find someone to work on it) -- that's the beauty of open-source -- and if you end up with a nice patch, it'll most likely be accepted and checked in.

Please also read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html - in particular, points #1 and #2

Comment 12

[Pietro]

Firefox Beta 6 seems to behave very well. Can someone confirm this?

Comment 13

[RNicoletto]

(In reply to comment #12)
> Firefox Beta 6 seems to behave very well. Can someone confirm this?
Confirmed on today's build. 

P.S. As per comment 11 please don't bump this bug anymore.

Comment 14

[Masatoshi Kimura [:emk]]

The maximum print job title length was 64 characters in legacy gfx.
http://mxr.mozilla.org/mozilla1.8/source/gfx/src/windows/nsDeviceContextWin.cpp#749
http://mxr.mozilla.org/mozilla1.8/ident?i=DOC_TITLE_LENGTH
Why Thebes changed the limit to 30 characters?
http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxWindowsSurface.cpp#200

Comment 15

[Daniel Holbert [:dholbert]]

Looks like the 30-char change dates back to 2006, in this checkin:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/gfx/thebes/src/gfxWindowsSurface.cpp&rev=1.11#141

There's no bug number included with the checkin comment, though ("adding Thebes printing APIs"), so I'm not sure if/where this change was discussed.

Comment 16

[Masatoshi Kimura [:emk]]

The maximum length of print job title is MAX_PATH (260) per MSKB.
http://support.microsoft.com/kb/281128

Comment 17

[Pietro]

|Looks like the 30-char change dates back to 2006, in this checkin:
|http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/gfx/thebes/src/gfxWindowsSurface.cpp&rev=1.11#141

So, I´m not a software professional, but isn´t that as simple as changing the value on line 141?

#define DOC_TITLE_LENGTH 260

Comment 18

[Masatoshi Kimura [:emk]]

Attachment: patch

Other browsers can print document titles whose length is longer than 30 (and even 64) characters without truncation. So I believe this restirction is unreasonable.
I changed the value of DOC_TITLE_LENGTH to (MAX_PATH-1) because MSKB says:
> The StartDoc function validates its parameters by checking that the length
> of the lpszDocName and the lpszOutput members of the DOCINFO structure are
> *less than* MAX_PATH.

Comment 19

[Masatoshi Kimura [:emk]]

Comment on attachment 490355 [details] [diff] [review]
patch

This is safe enough for branches and fix the regression since Fx 3.0.

Comment 20

[Masatoshi Kimura [:emk]]

Attachment: patch for 1.9.2 branch

Ah, trunk patch couldn't apply to the 1.9.2 branch because the file path had been changed.

Comment 21

[Masatoshi Kimura [:emk]]

Attachment: patch for 1.9.1 branch

Comment 22

[Pietro]

keep up the good work, Mr. Kimura

Comment 23

[Reed Loden [:reed]]

http://hg.mozilla.org/mozilla-central/rev/6478c1b83d60
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/328b5bce7df4
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/8f70e404d1ee

Comment 24

[Masatoshi Kimura [:emk]]

Sorry, mid-air collided

Comment 25

[Marcelo Bastos]

Bug 47080 and Bug 505010 are duplicates of this and should therefore be closed too.

Comment 26

[Marcelo Bastos]

Sorry, I meant " Bug 478080 " in the comment above.

Comment 29

[El Loco]

I just wanted to say, thank you thank you thank you!!  MAN that was a pain.  I had even gone so far as to download & TRY to compile the Mozilla source code (fail).  That saved me about 100+ hours & as I'm recovering from cubital tunnel surgery, wouldn't have been a good idea.

Again, thanks!!