202014 - OS X: add header/footer configuration for printing

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[sairuh (rarely reading bugmail)]

spun off from bug 188508. since Mac OS X now uses the native print dialog (as
well as native print preview and page setup), would it be possible to add option
for modifying the headers and footers? (see simon's comment in bug 188508
comment 1.)

in the native Page Setup dialog, you can modify the margins' sizes in the
"custom paper size" setting, but there's no setting/option for chosing the
content of the header and footers.

Comment 1

[Conrad Carlen (not reading bugmail)]

This would be nice to have. The 6 (!) popup menus that our XUL page setup dialog
offers is a bit much, whereas IE Mac's single checkbox is too simplistic. Also,
this UI really belongs in the page setup dialog instead of the print dialog but
that would require a whole new PDE. If the UI is simple enough, though, I think
it could be put in the print dialog PDE. 

Comment 2

[Kurt Raschke]

This remains unresolved as of Mozilla 1.3.1, but, more importantly, manually
specifying header and footer settings in a user.js file has no effect.  This
means that there is no way to generate output without headers or footers -- and
that is an important capability.

Bug 66713 appears to cover this issue as well, and it may be a duplicate.

Comment 3

[[:jberkus] Josh Berkus]

Guys: 
 
No offense, but the Header/Footer bug in OS X seems to have existed for TWO 
YEARS! (reference bug #66713)   I've got clients still using IE becuase of 
this; can't *somebody* look into it? 
 
-Josh 

Comment 4

[David Haas (gone, not reading mail)]

*** Bug 220201 has been marked as a duplicate of this bug. ***

Comment 5

[David Haas (gone, not reading mail)]

Attachment: a fix

here's my first crack at this.	It appears to work - although I've noticed 1
odd visual bug, and 1 unimplemented feature.  

visual bug: In selecting headers/footers, 2 items checked in the popup menu. 
Not sure how to turn this off or why it doesn't fix itself automatically.

missing feature: adding a "custom" header/footer string. I think this should
work like this: add an extra menu item to popup button that says "Custom". 
This is easy.  Selecting "custom" should trigger opening of a dialog window
with a text field.  I don't know how to do this in Carbon :(

I suspect the use of Mozilla string classes could be greatly improved. 
Otherwise, test it out & let me know what you think.

Comment 6

[David Haas (gone, not reading mail)]

Attachment: PrintPDE nib

Altered printing NIB file which goes along with above patch.

Comment 7

[David Haas (gone, not reading mail)]

Ack - sorry for the spam.  The patch in bug 220201 might complement this fix -
it reads the pref file (but only on 1st print job) to inialize the default
header/footer settings on all subsequent print jobs.  

Comment 8

[Conrad Carlen (not reading bugmail)]

Comment on attachment 136081 [details] [diff] [review]
a fix

>Index: mozilla/embedding/components/printingui/src/mac/nsPrintingPromptServiceX.cpp
>===================================================================
>+    nsXPIDLString headerRight;
>+    printSettings->GetHeaderStrRight(getter_Copies(headerRight));
>+    printData.mHeaderRight = CFStringCreateWithCharacters(NULL,headerRight.get(),headerRight.Length());

I don't see these strings ever being released.


>+            CFRange range = CFRangeMake(0,0);
>+            CFIndex len;
>+            // malloc a temp buffer
>+            PRUnichar *buffer = (PRUnichar *)malloc(sizeof(PRUnichar) * kBufSize);
>+            if (buffer) {
>+            
>+              if (printData.mHeaderRight != NULL) {
>+               len = CFStringGetLength(printData.mHeaderRight);
>+               range.length = len < kBufSize ? len:(kBufSize-1);

Rather than going to the trouble of allocating, and then still possibly not
having enough room, use an autobuffer of some sort. There's a patch for a
general, template version of one on bug 161982. nsLocalFileOSX does somthing
similar in its own code.

>+               CFStringGetCharacters(printData.mHeaderRight, range, buffer);
>+               buffer[range.length+1] = PRUnichar('\0');
>+               tempStr.Assign(buffer);
>+              } else
>+                 tempStr.Assign(NS_LITERAL_STRING(""));
>+              printSettings->SetHeaderStrRight(tempStr.get());
>+            
>Index: mozilla/embedding/components/printingui/src/mac/printpde/src/PDECustom.c
>===================================================================

Looks fine here, except I don't see anything added to MyGetSummaryText() for
the new items. That needs to be complete.

Comment 9

[David Haas (gone, not reading mail)]

IIRC, MyGetSummaryText was just for localization of labels which couldn't be set
in the NIB.  Since the text of the pop-up buttons can be set in the NIB so
therefore can be changed without having to recompile, do you really want new
code added to that method?

Otherwise, the changes are straightforward.  Let me know about this one issue
and I'll submit a fixed patched.  

Comment 10

[Conrad Carlen (not reading bugmail)]

> IIRC, MyGetSummaryText was just for localization of labels

No, it doesn't have to do with labels. It's a separate, information panel. To
see it, choose "Summary" from the main menu in the Print dialog. The text that
appears in that panel is generated by MyGetSummaryText().

Comment 11

[Jasper]

*** Bug 233067 has been marked as a duplicate of this bug. ***

Comment 12

[Asa Dotzler [:asa]]

*** Bug 236955 has been marked as a duplicate of this bug. ***

Comment 13

[Conrad Carlen (not reading bugmail)]

In addition to the small problems I pointed out with the patch, it has a
fundamental problem:

diff -u -6 -p -r1.2 nsPDECommon.h
---
mozilla/embedding/components/printingui/src/mac/printpde/public/nsPDECommon.h	3
Apr 2003 19:19:55 -0000	1.2
+++
mozilla/embedding/components/printingui/src/mac/printpde/public/nsPDECommon.h	22
Nov 2003 04:19:03 -0000
@@ -54,12 +54,20 @@ typedef struct {
   Boolean mPrintSelectedFrame;
   Boolean mPrintFramesSeparately;
   Boolean mPrintSelection;
   Boolean mShrinkToFit;
   Boolean mPrintBGColors;
   Boolean mPrintBGImages;
+  // Header/Footer gets passed as a CFStringRef
+  CFStringRef mHeaderRight;
+  CFStringRef mHeaderCenter;
+  CFStringRef mHeaderLeft;
+  CFStringRef mFooterRight;
+  CFStringRef mFooterCenter;
+  CFStringRef mFooterLeft;
+  
 } nsPrintExtensions;

CFStringRefs cannot be added to this struct. This struct, since to this point
contained only Booleans, is written out to the print record as POD. Obviously,
that doesn't work with pointers. Using this patch, if you save custom settings,
you will crash next time around.

The simple fix would be to replace CFStringRefs with a fixed size array of
Unichars. Better yet, this data can be stored on the print record as a
CFDictionay and then things can easily be added as time goes by.

Comment 14

[Jasper]

bump

Comment 15

[Hiro]

*** Bug 259488 has been marked as a duplicate of this bug. ***

Comment 16

[Josh Whitver]

After seeing discussions on this, and even some proposed code, this STILL hasn't been implemented?!?  
Could someone ***PLEASE*** roll this into a build somewhere?  Even if it's just a nightly?  We 
desperately need a version of Camino that can disable headers and footers!

Comment 17

[Jo Hermans]

*** Bug 268388 has been marked as a duplicate of this bug. ***

Comment 18

[Chris Lawson (gone)]

(In reply to comment #3)
> Guys: 
>  
> No offense, but the Header/Footer bug in OS X seems to have existed for TWO 
> YEARS! (reference bug #66713)   I've got clients still using IE becuase of 
> this; can't *somebody* look into it? 
>  
> -Josh 

Make that three years.

Please?

--cl

Comment 19

[Chris Lawson (gone)]

On further examination...

Would it be possible to mess around with the .nib or .xib files in the PrintPDE
plugin to fix this? I'd be happy to put out an unsupported patch/hack/workaround
if it can be done this way. I just don't have the time or inclination to work
directly on the source code.

Anyone know?

cl

Comment 20

[Conrad Carlen (not reading bugmail)]

> Would it be possible to mess around with the .nib or .xib files in the PrintPDE
plugin to fix this?

No, it takes code. I'll try and get to this soon.

Comment 21

[Mike Pinkerton (not reading bugmail)]

we're past 1.7, on the 1.8a train....

Comment 22

[Hiro]

*** Bug 271810 has been marked as a duplicate of this bug. ***

Comment 23

[Kurt Raschke]

This bug actually affects Mozilla, Camino, and Firefox...do new bugs need to be
opened separately for Camino and Firefox, or will this issue be resolved for all
three browsers at once?

Also, is there any estimate as to when this issue may be resolved?

-Kurt

Comment 24

[Conrad Carlen (not reading bugmail)]

> or will this issue be resolved for all three browsers at once?

They all use the same Printer Dialog Extension and printing code, so they'll all be fixed at once

> Also, is there any estimate as to when this issue may be resolved?

I should be able to find some time over the Xmas holiday

Comment 25

[Jo Hermans]

*** Bug 276221 has been marked as a duplicate of this bug. ***

Comment 26

[Stephen Rauchle]

(In reply to comment #0)
I am not a programmer so please bear with me - in OS X 1.3.7 IE has the
settings. Safari 1.2.4 does not have a way to set this but must be reading the
IE settings as it does not print the header/footer. Is there a way for
Mozilla/Camino/Firefox to emulate the IE settings?

Comment 27

[Chris Lawson (gone)]

Yes, it would be possible for Camino/Firefox/Mozilla to emulate the behaviour of IE.

That's what Conrad is working on over the holiday. Like he said, the code needs
to be re-worked to support those preferences, and no one has gotten around to it
yet.

FWIW, if you really need the page without header/footer info, a workaround for
the moment is to use Safari. Obviously this isn't an option if KHTML and Gecko
render differently, but it's a start.

Conrad, any word on progress?

cl

Comment 28

[Conrad Carlen (not reading bugmail)]

> Conrad, any word on progress?

I'm working on it. I was hoping to be able to exchange settings between the app
and the plugin using a CFDictionary, so we can add keys to it as needed without
invalidating older data stored in print settings. Unfortunately, the data has to
be in the form of plain CFData. If a dictionary is used, it has to be flattened
to/from a property list which can be wrapped in CFData. If that turns out to be
more work than I have time for, I'll just do the simple approach of extending
the existing data structure.

Comment 29

[Conrad Carlen (not reading bugmail)]

Attachment: new patch

New patch uses a CFDictionary to exchange settings between the app and the PDE,
so we can easily expand in the future without having to discard saved print
settings.   Saving it to custom print settings works as well.

Comment 30

[Conrad Carlen (not reading bugmail)]

Attachment: English.lproj/Localizable.strings

This is a binary file to CVS (it's really Unicode text) so doesn't show in the
diff

Comment 31

[Asa Dotzler [:asa]]

Who can review this? Simon, can you help here?

Comment 32

[Simon Fraser [no longer active]]

Comment on attachment 170107 [details] [diff] [review]
new patch

Sure, will take me a bit of time tho.

Comment 33

[Asa Dotzler [:asa]]

not going to block the release for this but we'd consider reviewed patches if
there's time.

Comment 34

[Simon Fraser [no longer active]]

Comment on attachment 170107 [details] [diff] [review]
new patch

> Index: printingui/src/mac/nsPrintingPromptServiceX.cpp
> ===================================================================

> +        printSettings->GetHeaderStrRight(getter_Copies(xpidlString));
> +        cfString = CFStringCreateWithCharacters(NULL,xpidlString.get(), xpidlString.Length());
> +        if (cfString) {
> +            CFDictionaryAddValue(dictToPDE, kPDEKeyHeaderRight, cfString);
> +            CFRelease(cfString);
> +        }
> +        printSettings->GetHeaderStrCenter( getter_Copies(xpidlString));
> +        cfString = CFStringCreateWithCharacters(NULL,xpidlString.get(), xpidlString.Length());
> +        if (cfString) {
> +            CFDictionaryAddValue(dictToPDE, kPDEKeyHeaderCenter, cfString);
> +            CFRelease(cfString);
> +        }
> +        printSettings->GetHeaderStrLeft( getter_Copies(xpidlString));
> +        cfString = CFStringCreateWithCharacters(NULL,xpidlString.get(), xpidlString.Length());
> +        if (cfString) {
> +            CFDictionaryAddValue(dictToPDE, kPDEKeyHeaderLeft, cfString);
> +            CFRelease(cfString);
> +        }
> +        printSettings->GetFooterStrRight(getter_Copies(xpidlString));
> +        cfString = CFStringCreateWithCharacters(NULL,xpidlString.get(), xpidlString.Length());
> +        if (cfString) {
> +            CFDictionaryAddValue(dictToPDE, kPDEKeyFooterRight, cfString);
> +            CFRelease(cfString);
> +        }
> +        printSettings->GetFooterStrCenter( getter_Copies(xpidlString));
> +        cfString = CFStringCreateWithCharacters(NULL,xpidlString.get(), xpidlString.Length());
> +        if (cfString) {
> +            CFDictionaryAddValue(dictToPDE, kPDEKeyFooterCenter, cfString);
> +            CFRelease(cfString);
> +        }
> +        printSettings->GetFooterStrLeft( getter_Copies(xpidlString));
> +        cfString = CFStringCreateWithCharacters(NULL,xpidlString.get(), xpidlString.Length());
> +        if (cfString) {
> +            CFDictionaryAddValue(dictToPDE, kPDEKeyFooterLeft, cfString);
> +            CFRelease(cfString);
> +        }

Maybe make some small helper methods to reduce the code duplication?

> +        CFDictionaryRef dictFromPDE = ExtractCustomSettingsDict(nativePrintSettings);
> +        if (dictFromPDE) {
> +            CFShow(dictFromPDE);

Remove the CFShow()  ;)

> +            
> +            if ((dictValue = CFDictionaryGetValue(dictFromPDE, kPDEKeyHeaderLeft)) &&
> +                (CFGetTypeID(dictValue) == CFStringGetTypeID())) {
> +                stringLen = CFStringGetLength((CFStringRef)dictValue);
> +                if (stringBuffer.EnsureElemCapacity(stringLen + 1)) {
> +                    CFStringGetCharacters((CFStringRef)dictValue, CFRangeMake(0, stringLen), stringBuffer.get());
> +                    stringBuffer.get()[stringLen] = 0;
> +                    printSettings->SetHeaderStrLeft(stringBuffer.get());
> +                }
> +            }
> +            if ((dictValue = CFDictionaryGetValue(dictFromPDE, kPDEKeyHeaderCenter)) &&
> +                (CFGetTypeID(dictValue) == CFStringGetTypeID())) {
> +                stringLen = CFStringGetLength((CFStringRef)dictValue);
> +                if (stringBuffer.EnsureElemCapacity(stringLen + 1)) {
> +                    CFStringGetCharacters((CFStringRef)dictValue, CFRangeMake(0, stringLen), stringBuffer.get());
> +                    stringBuffer.get()[stringLen] = 0;
> +                    printSettings->SetHeaderStrCenter(stringBuffer.get());
> +                }
> +            }
> +            if ((dictValue = CFDictionaryGetValue(dictFromPDE, kPDEKeyHeaderRight)) &&
> +                (CFGetTypeID(dictValue) == CFStringGetTypeID())) {
> +                stringLen = CFStringGetLength((CFStringRef)dictValue);
> +                if (stringBuffer.EnsureElemCapacity(stringLen + 1)) {
> +                    CFStringGetCharacters((CFStringRef)dictValue, CFRangeMake(0, stringLen), stringBuffer.get());
> +                    stringBuffer.get()[stringLen] = 0;
> +                    printSettings->SetHeaderStrRight(stringBuffer.get());
> +                }
> +            }
> +            if ((dictValue = CFDictionaryGetValue(dictFromPDE, kPDEKeyFooterLeft)) &&
> +                (CFGetTypeID(dictValue) == CFStringGetTypeID())) {
> +                stringLen = CFStringGetLength((CFStringRef)dictValue);
> +                if (stringBuffer.EnsureElemCapacity(stringLen + 1)) {
> +                    CFStringGetCharacters((CFStringRef)dictValue, CFRangeMake(0, stringLen), stringBuffer.get());
> +                    stringBuffer.get()[stringLen] = 0;
> +                    printSettings->SetFooterStrLeft(stringBuffer.get());
> +                }
> +            }
> +            if ((dictValue = CFDictionaryGetValue(dictFromPDE, kPDEKeyFooterCenter)) &&
> +                (CFGetTypeID(dictValue) == CFStringGetTypeID())) {
> +                stringLen = CFStringGetLength((CFStringRef)dictValue);
> +                if (stringBuffer.EnsureElemCapacity(stringLen + 1)) {
> +                    CFStringGetCharacters((CFStringRef)dictValue, CFRangeMake(0, stringLen), stringBuffer.get());
> +                    stringBuffer.get()[stringLen] = 0;
> +                    printSettings->SetFooterStrCenter(stringBuffer.get());
> +                }
> +            }
> +            if ((dictValue = CFDictionaryGetValue(dictFromPDE, kPDEKeyFooterRight)) &&
> +                (CFGetTypeID(dictValue) == CFStringGetTypeID())) {
> +                stringLen = CFStringGetLength((CFStringRef)dictValue);
> +                if (stringBuffer.EnsureElemCapacity(stringLen + 1)) {
> +                    CFStringGetCharacters((CFStringRef)dictValue, CFRangeMake(0, stringLen), stringBuffer.get());
> +                    stringBuffer.get()[stringLen] = 0;
> +                    printSettings->SetFooterStrRight(stringBuffer.get());
> +                }

More chance for code factoring?

> Index: printingui/src/mac/printpde/src/PDECustom.c
> ===================================================================

> +static void InternSettings(CFDictionaryRef srcDict, MySettings* settings)

The name "InternSettings" is a bit opaque to me. Is this
GetSettingsFromDictionary() ?

> +    if ((dictValue = CFDictionaryGetValue(srcDict, kPDEKeyPrintSelection)) &&
> +        (CFGetTypeID(dictValue) == CFBooleanGetTypeID()))
> +            settings->mPrintSelection = CFBooleanGetValue((CFBooleanRef)dictValue); 
> +    if ((dictValue = CFDictionaryGetValue(srcDict, kPDEKeyShrinkToFit)) &&
> +        (CFGetTypeID(dictValue) == CFBooleanGetTypeID()))
> +            settings->mShrinkToFit = CFBooleanGetValue((CFBooleanRef)dictValue);
> +    if ((dictValue = CFDictionaryGetValue(srcDict, kPDEKeyPrintBGColors)) &&
> +        (CFGetTypeID(dictValue) == CFBooleanGetTypeID()))
> +            settings->mPrintBGColors = CFBooleanGetValue((CFBooleanRef)dictValue);
> +    if ((dictValue = CFDictionaryGetValue(srcDict, kPDEKeyPrintBGImages)) &&
> +        (CFGetTypeID(dictValue) == CFBooleanGetTypeID()))
> +            settings->mPrintBGImages = CFBooleanGetValue((CFBooleanRef)dictValue);

Maybe factor with helper methods?

> +    if ((dictValue = CFDictionaryGetValue(srcDict, kPDEKeyHeaderLeft)) &&
> +        (CFGetTypeID(dictValue) == CFStringGetTypeID()))
> +            settings->mHeaderLeft = MyCFAssign(dictValue, settings->mHeaderLeft);
> +    if ((dictValue = CFDictionaryGetValue(srcDict, kPDEKeyHeaderCenter)) &&
> +        (CFGetTypeID(dictValue) == CFStringGetTypeID()))
> +            settings->mHeaderCenter = MyCFAssign(dictValue, settings->mHeaderCenter);
> +    if ((dictValue = CFDictionaryGetValue(srcDict, kPDEKeyHeaderRight)) &&
> +        (CFGetTypeID(dictValue) == CFStringGetTypeID()))
> +            settings->mHeaderRight = MyCFAssign(dictValue, settings->mHeaderRight);
> +    if ((dictValue = CFDictionaryGetValue(srcDict, kPDEKeyFooterLeft)) &&
> +        (CFGetTypeID(dictValue) == CFStringGetTypeID()))
> +            settings->mFooterLeft = MyCFAssign(dictValue, settings->mFooterLeft);
> +    if ((dictValue = CFDictionaryGetValue(srcDict, kPDEKeyFooterCenter)) &&
> +        (CFGetTypeID(dictValue) == CFStringGetTypeID()))
> +            settings->mFooterCenter = MyCFAssign(dictValue, settings->mFooterCenter);
> +    if ((dictValue = CFDictionaryGetValue(srcDict, kPDEKeyFooterRight)) &&
> +        (CFGetTypeID(dictValue) == CFStringGetTypeID()))
> +            settings->mFooterRight = MyCFAssign(dictValue, settings->mFooterRight);

Maybe factor with helper methods here too?

Otherwise it looks good!

Comment 35

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 170107 [details] [diff] [review]
new patch

Index: printingui/src/mac/printpde/public/nsPDECommon.h
...
 #endif
\ No newline at end of file

fix that, r=pink

Comment 36

[Conrad Carlen (not reading bugmail)]

Thanks for the reviews. Simon, I'll take your suggestions and check in a
better-factored version. I'm in the process of re-getting CVS access since they
locked it down and got rid of pserver access.

Comment 37

[Hiro]

*** Bug 280310 has been marked as a duplicate of this bug. ***

Comment 38

[Matt Oakey]

Hey Everyone!
I'm the guy who started all this (66713) way back when, and I must say it sure
has made the rounds through you all!
By the way,
<<Netscape 7.2 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2)
Gecko/20040804 Netscape/7.2 (ax))>>
has this capability in the wintel version, I haven't checked but I think it is
also there in the MacOSX version. I have no idea about the Mozilla/Firefox
products but would assume YES since they all use the same Gecko engine, no?
Keep up all the excellent work !

Comment 39

[Microsoft Office Specialist]

When will this be fixed? I can't use Firefox until I can turn off my headers and
footers. I'll remain an unhappy Safari/IE user until this feature works via
about:config.

Comment 40

[Chris Lawson (gone)]

Any more progress on this in the last two months?

cl

Comment 41

[Conrad Carlen (not reading bugmail)]

> Any more progress on this in the last two months?

The patch works and is reviewed. It could benefit by some of the factorization
suggested by Simon, but it has sr= without it.

The stopper for me was that CVS access is no longer via pserver, so I sent my
public key to mozilla.org so I could check it in.   My account was still active,
but after having my key added, I was not able to get secure CVS access working.
I didn't have any time to play around with it. I think the shortest path to
getting this checked in is for somebody with working CVS write access to take
the bug. 

Comment 42

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I don't want to sound rude, but it's been two weeks since Conrad asked/suggested
someone else should check this in and it's still sitting here waiting for
checkin, 4 months after r/sr.

If the patch still applies cleanly, is there no one cc'd who would check it in?

Comment 43

[Simon Fraser [no longer active]]

This needs to get approval for mozilla.

Comment 44

[Mike Pinkerton (not reading bugmail)]

-> simon since he's landing a bunch of stuff these days.

Comment 45

[Mike Pinkerton (not reading bugmail)]

we get a lot of feedback *begging* for a way to turn these headers/footers off.
We have a fix, let's get this landed. Can we get some approval love?

Comment 46

[Stefan [:stefanh]]

Comment on attachment 170107 [details] [diff] [review]
new patch

> we get a lot of feedback *begging* for a way to turn these headers/footers off.
> We have a fix, let's get this landed. Can we get some approval love?

Asking approval, since the patch is there.

Comment 47

[Benjamin Smedberg]

oof, this sucks as a last-minute-before-branching patch. Can I get a risk
assessment (I think I'm pretty well aware of the rewards!).

Comment 48

[Simon Fraser [no longer active]]

I've built and tested this in Deer Park and Camino, and it works just fine. It's
quite a bit of code (mostly stuffing and unstuffing CFDictionaries, and hooking
up the new UI). It's pretty low risk, and I think we should get it in.

Comment 49

[Simon Fraser [no longer active]]

Checked in.

Comment 50

[Josh Whitver]

On behalf of those of us who've been waiting YEARS for this, let me say:

THANKYOUTHANKYOUTHANKYOUTHANKYOU!!

Comment 51

[Jo Hermans]

When I enter this dialog box, I can see that the popups aren't working
correctly. For example, in the page-header-left popup, both "(Blank)" and
"Title" are selected in the popup.

Comment 52

[Simon Fraser [no longer active]]

(In reply to comment #51)
> When I enter this dialog box, I can see that the popups aren't working
> correctly. For example, in the page-header-left popup, both "(Blank)" and
> "Title" are selected in the popup.

What do you mean by "both are selected"? Is it a drawing issue? Can you attach a
small screenshot (as PNG).

Comment 53

[Jo Hermans]

Attachment: 2 options checked

I opened a Print Dialog, went to the Deer Park tab, and selected the first
popup.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050808
Firefox/1.0+

Mac OS X 10.28

Comment 54

[Simon Fraser [no longer active]]

Ah, OK. I can't reproduce that on 10.4, and it looks like you are on 10.2.

Comment 55

[Jo Hermans]

(In reply to comment #54)
> Ah, OK. I can't reproduce that on 10.4, and it looks like you are on 10.2.

The print iself is ok, it seems only an issue in the GUI. The (Blank) entry is
shown selected at first, but isn't used. When you select it again, it will be used.

I think it's caused by the checked-entry (set to TRUE) that is set for the blank
items by default (look for IBCarbonMenuItem), but not for the other. Maybe it's
never reset on Mac OS X 10.2.8.

PS: there's also a spelling mistake in the comment for
CFCopyLocalizedStringFromTableInBundle : look for ther string 'Heaader'.

Comment 56

[Jo Hermans]

filed bug 304126 for that issue