78319 - [FIX]Win32: issue of print dialog localization

Status: VERIFIED FIXED

(Core :: Printing: Output, defect, P2)

Description

[Masaki Katakai]

I tried to localize Mozilla print dialog for Windows platform. However I could
not find "Print range" keyword in .dtd files and .propertiles file.

I found such keyword and other words in the file,

 http://lxr.mozilla.org/seamonkey/source/widget/src/build/widget.rc

It seems that Windows resource file. Is the print dialog created by this file?
If so, I'd like to know how we localize the file for each language? Do we
need to modify rc files and ship Windows the file in Mozilla??

We should use .dtd and .properties files for localization in Mozilla.
So this dialog breaks the theory.

On UNIX platform, gtk based print dialog had been used but we
have rewritten in XUL for localization and UI consistency.

Comment 1

[Jaime Rodriguez, Jr.]

Nominating for nsbeta1. Please set milestone as M0.9.1.

Adding mcarlson and danielmc to cc: list.

Is this a l12y issue. If so, we should remove "intl" and leave "l12y"

Comment 2

[tao]

Although this seems to be pure l12y; most people use 'intl' to cover both i18n
 & l12y. I'd suggest to keep it. It's your call, though.

Comment 3

[Kevin McCluskey (gone)]

Reassigning to Rod

Comment 4

[rods (gone)]

After thinking about this, the issue is, when you use the native dialog from the 
system is it localized by Windows for whatever version of I18N Windows that is 
being used. 

Now that we have our own copy of the dialog we will have to localize it. By 
either:

1) Creating a .rc file for each localization
2) Using a properties file and attempting to change the strings in the dialog, 
but this may cause some UI problems with iszing.
3) If Microsoft sells the compiler in dfferent languages we could buy/get/have 
copies of these dev kits use the localized versions available there much like we 
used for the English version.

Comment 5

[Michele Carlson]

Ray - can you comment on this please?

Comment 6

[Jaime Rodriguez, Jr.]

changing to nsbeta1-.

Comment 7

[rchen]

It's hard to believe we use Win32 for print dialog while the rest of the browser 
using XUL or properties files.  

Please, we don't localize RC files. This is a critical bug for l10n. 

ftang, can you nominate nsbeta1+?

Comment 8

[Jaime Rodriguez, Jr.]

Ray - We got your comment, but we need to know the impact of this issue (i.e. 
How does it affect the user or development)?

Comment 9

[Kevin McCluskey (gone)]

Creating a XUL dialog for the print dialog is a "BIG job". We would have to
design and implement api's to cycle through all of the available printers and
report each printers status and location. In addition we would have to  bring up
native printer driver dialogs. (On WIN32 the native printer driver dialogs are
brought up using the Properties button on the print dialog)

Comment 10

[rchen]

First, rc file is only good for Win32. It is not cross platform. That means we 
will have three localization for three platforms. Second, it requires the 
compiling and build processes, which we should avoid. 

Another way to localize Win32 is to localize the binary file. Again, there will 
be three loclaization for three platforms.  Binary file localization is 
also troublesome. It needs special tools.

I am afraid we have to live with the english dialog at this point, if we don't 
fix this bug.

Comment 11

[Jaime Rodriguez, Jr.]

Kevin - This is big job either way. Either its a big job for L10N to localize 
across 3 platforms for every release, or one "big job" to make this localizable. 
 This is currently marked as M0.9.2. Do you think you or Rod will get to it 
during M0.9.2? Can we fix this one early on in the cycle, since it is a "big 
job"? I'd hate to see it wait listed, and then moved to another release. Pls 
help . . .

Adding phil, lyecies, roberts, and bobj to cc: list.

Comment 12

[Kevin McCluskey (gone)]

Doing a XUL dialog replacement for the print dialog would take approx 3 man
weeks to get all of the native backend printing support working on WIN32. There
would also be some additional time to create and hookup the XUL dialog. The
resulting implementation would be "risky". There is a poorly documented but
extremely large data structure that is initialized by the native print dialog on
WIN32. We would have to make sure that there weren't any differences between
WIN95, WIN98, WINNT, WIN2K in regards to the initialization of this data.

I propose we continue to use the native print dialog, but we add a property file
which we use to set the labels on the native print dialog. The property file
will be used on both WIN32 and Mac to do localization. On Linux we already use a
XUL dialog for the print dialog which is localized through a dtd file.

We will also need to create an additional large native print dialog which will
have plenty of room for languages that have strings which will not fit in the
space provided by the default printer dialog. The property file will need to
contain an entry which indicates which dialog should be used (default or large).
We will need some help from the internationalization team to get an idea of what
the worst case would be for the length of the labels in the buttons,radio
buttons etc.

Rod and I estimate that this could be done with approx 3 days of effort. The Mac
implementation would probably take 1 to 2 days once the WIN32 code was complete.

  

Comment 13

[rchen]

Kevin's proposal looks good to me. Just be careful of the fonts and charsets 
when sets up the native dialog for different locale.   

Comment 14

[bobj]

The font info should also be externalized to a property file.
Can we also externalize the sizing information to a property file?

Strings in the Java-style property files are expected to be in escaped Unicode.
So the strings will need to be converted before used by the Windows resources.

Comment 15

[rods (gone)]

Attachment: patch - jat file for properties

Comment 16

[rods (gone)]

Attachment: us-EN printing.properties

Comment 17

[rods (gone)]

Attachment: actual patch file

Comment 18

[rods (gone)]

The previous three attachments will enable the native Windows print dialog to be 
localized. The jar.mn and printing.properties file should go into 
/mozilla/gfx/src

Our thinking for this goes as follows:
Currently, the code uses the PRINTDLGNEW template that is defined in the 
/mozilla/widget/src/build/widget.rc file.

We will create an additional template with more space allocated for the labels 
which can be used for locales where the text will not easily fit in the current 
template. The properties file can then determine which template will be used. 
The attached printing.properties file has "templateName=PRINTDLGNEW" defined.

Hopefully most all locales will fit into either of these dialog templates.

As far as the dialog font goes, I thought on Windows one of the font names was 
considered to be a default font and for other locales the correct font was 
substituted. Frank, is this correct? Is it "Serif"? or "MS Sans Serif"?

(I may rename the printing.properties to printdialog.properties, and the 
StringBundle code may be moved to a different file where it can be used by more 
than just the windows library)

Comment 19

[Jaime Rodriguez, Jr.]

Thanks for the help and proposal Kevin. Much appreciated. Is this something we 
all believe we can get in by the end of this week?

Comment 20

[rods (gone)]

I need someone to localize the printing.properties file in a language that would  
have the largest strings, German? And send it to me so I can create the other 
dialog template. Thanks.

Comment 21

[rods (gone)]

This is a reply to bobj's questions:

I am assuming the string bundle service can read in the escaped-strings 
correctly into an nsString and from there I am using Unicode. We could put 
sizing and layout info in the properties file, but I would rather not spend a 
lot of time writing a layout manager for the print dialog when we will 
eventually be switching over to a XUL-based dialog. I am hoping that all 
languages could be covered "creatively" using two or perhaps even three 
different templates.

Comment 22

[bobj]

> I am assuming the string bundle service can read in the escaped-strings 
> correctly into an nsString and from there I am using Unicode.

Correct, but what I'm concerned about is that the Windows (at least Win9x)
resources will probably need the Unicode strings converted to the "native"
encodings (e.g., cp1252, shift-jis).  There may be no problem on NT and W2K,
but .rc files are not Unicode based on Win9x.

Ray, Please clarify if I've misspoken.

Comment 23

[rods (gone)]

I am changing the strings dynamically when the WM_INITDIALOG is being processed 
during the creation of the PrintDialog. 

I am calling ::SetWindowTextW and passing in Unicode, which I am not 100% sure 
whether I am suppose to be doing that, or what effect it might have on Win95/98. 
Does anybody know? I should probably be using just SetWindowText.

Also, you said "need the Unicode strings converted to the 'native' encodings 
(e.g., cp1252, shift-jis)" I wouldn't have a clue as to what I should do for 
that, I will need help.

Comment 24

[Jaime Rodriguez, Jr.]

DanielMC - Can you help us out here???

Comment 25

[bobj]

Assuming ::SetWindowTextW works fine on Win9x, your approach sounds like it
should work.  But historically, Unicode support on Win9x has had problems.

Since, I'm a pointy headed type, I've forwarded this bug to the I18N engineers
who should be able to provide accurate details on how this really works. Thx.

Comment 26

[rchen]

Bob, you are right. I think Rod needs the help on fonts and charset issues.  
It will be helpful if we can show him a piece of code from some other place.

Comment 27

[rods (gone)]

rchen, yes that would be great to be have some pointers to code I can use.

I don't think SetWindowTextW will work on Win95, the docs say it only supports 
Unicode on Win2K and NT as was stated earlier in this bug.

Comment 28

[danielmc]

Rose, can you attach a printing.properties in German and also generate a Pseudo 
trnaslated file from TML with 30% expansion

Comment 29

[danielmc]

sorry Rose, I mean printdialog.dtd

Comment 30

[Rose Smyth]

Attachment: DE printdialog.dtd

Comment 31

[Rose Smyth]

Attachment: Pseudo translated printdialog.dtd

Comment 32

[nhottanscp]

Pasting from e-mail:

Naoki Hotta wrote:
> I think this is what Frank mentioned.
> http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp#4311

> 4311 static char* GetACPString(const nsString& aStr)
> 4312 {
> 4313    int acplen = aStr.Length() * 2 + 1;
> 4314    char * acp = new char[acplen];
> 4315    if(acp)
> 4316    {
> 4317       int outlen = ::WideCharToMultiByte( CP_ACP, 0,
> 4318                       aStr.GetUnicode(), aStr.Length(),
> 4319                       acp, acplen, NULL, NULL);
> 4320       if ( outlen > 0)
> 4321          acp[outlen] = '\0';  // null terminate
> 4322    }
> 4323    return acp;
> 4324 }
> > Yung-Fong Tang wrote:
>
> > Roy and Naoki, can you help?
> > I believe ::SetWindowTextW is ok for NT. For 95/98, I don't think that
> > will work, you probably need to convert to system charset and call
> > SetWindowTextA for it. See GetACPString in widget/src/windows for how to
> > do that.

Comment 33

[rchen]

If I remember correctly. WideCharToMultiByte Windows API is good for both 
multibyte and single byte charset. It also works for NT, 95/98.  After 
converting the Unicode strings to the "native" strings with GetACPString or 
WideCharToMultiByte, SetWidnowText should be able to take care of it. Regarding 
the font, it should be the same one used in other dialogs. 

Comment 34

[rods (gone)]

Thanks this method will also help me fix Bug 71542

Then this should work for setting the text:

static void SetTextOnWnd(HWND aControl, const nsString& aStr)
{
  char* pStr = nsDeviceContextWin::GetACPString(aStr);
  if (pStr) {
    ::SetWindowText(aControl, pStr);
    delete [] pStr;
  }
}

Comment 35

[rods (gone)]

Attachment: complete patch (except for jar.mn, printdialog.properties, & widget.rc)

Comment 36

[rods (gone)]

Attachment: jar.mn

Comment 37

[rods (gone)]

Attachment: printdialog.properties

Comment 38

[rods (gone)]

Attachment: widget.rc

Comment 39

[Kevin McCluskey (gone)]

Could use a comment to indicate that the second value in 
PropKeyInfo gAllPropKeys is mapped to the ID of the control in the dialog box 
template. 

printdialog_properties
What will happen on the Mac with the & character used for keyboard accelerator? 
Will it display? May need to have the Mac filter out these characters.

widget.rc
Should really be a diff file, instead of the entire printdialog rc file.
The default printdialog is already checked in. This rc file includes an 
additional large dialog for languages which have strings which are too long for 
the default printdialog.

r=[e-mail]

Comment 40

[Chris Waterson]

sr=waterson

Comment 41

[rods (gone)]

Attachment: final patch with minor changes suggested by reviewers

Comment 42

[Jaime Rodriguez, Jr.]

Looks like this is cooked. Request that we try and move this to M0.9.1.

Comment 43

[Christopher Blizzard (:blizzard)]

a=blizzard for 0.9.1

Comment 44

[Kevin McCluskey (gone)]

Attachment: nsDeviceContext.h file changes

Comment 45

[Kevin McCluskey (gone)]

Moving to mozilla0.9.1

Comment 46

[Kevin McCluskey (gone)]

Don checked in the fix.

Comment 47

[Tsukasa Maruyama]

Attachment: printdialog.properties translated \uxxxx form

Comment 48

[Tsukasa Maruyama]

I'm making mozilla Japanese Localization Package.
I tried to Print dialog to localize Japanese.(Build ID: 2001052620 for win)
but cannot view Japanese.
These patch not able to \uxxxx format conversion?

attached Japanized printdialog.properties \uxxxx format.

Comment 49

[bobj]

> I tried to Print dialog to localize Japanese.(Build ID: 2001052620 for win)
> but cannot view Japanese.
> These patch not able to \uxxxx format conversion?

Mozilla property files support the \uxxxx format.

The "fix" comment was from 5/26 evening, so the fixes may not have been
in the 2001052620 build.

I assume you are running on Japanese Windows.  The current implementation
relies upon a localized OS for the localized strings to display properly.
GetACPString returns the code page of the system.  When we migrate to XUL,
then we should no longer have this restriction.

Comment 50

[bobj]

Maruyama-san,  Have you tried your Japanized printdialog.properties with
a later build?

Comment 51

[Tsukasa Maruyama]

Attachment: At Build ID 2001053020 Japanesed printdialog view on Win2000+SP1(JP)

Comment 52

[Tsukasa Maruyama]

I tried to Japanized Build ID 2001053020 mozilla that use same
printdialog.properties.
But also cannot view Japanese. I attached PrintDialog Image, too.

Comment 53

[rods (gone)]

The method "GetACPString" was being used in nsWindow.cpp for setting the title 
of the dialog, which is interesting, because it works for the title of the 
dialog here also, but is broken for the controls. 

I am assuming the maybe the font is set wrong for the controls?

So maybe the dialog has it's font set correctly, but the controls do not?

Any ideas? (I am reopening the bug and setting it to be a 0.9.2 issue)

Comment 54

[rchen]

Can we use system font for the controls for now? Otherwise we have to have the 
font valuable in the properties file for localization.

Comment 55

[rods (gone)]

The SYSTEM_FONT on Windows does not match the dialog gui font, so we will have 
to specify a font in the properties file. 

But we could specify it as follows:

font=default_gui
font=default_system

or we could other meaningful values.

I will attach a patch for this implementation.

Comment 56

[rods (gone)]

Attachment: patch for being able to specify the "system" font.

Comment 57

[bobj]

In addtion to the latest patch, I assume you'll add a line to en-us
printdialog.properties, either
   font = MS Sans Serif
or
   font=default_gui
or
   font=default_system

Whichever we choose, we should add a comment explaining the the options for
specifying the font: "default_gui", "default_system", or real font name.

Do we need to externalized the font size?  From widget.rc, it looks like it is
hard coded to "8".  Is that going to be too small for some Asian fonts?

Comment 58

[Roy Yokoyama]

cc'ing [e-mail]

For your last patch, you may want to check for hFont 
before calling ::DeleteObject(hFont) like:
     }
+    if (hFont != NULL) 
+      ::DeleteObject(hFont);
+
     nsAutoString titleStr;
       
If you decide to provide real font name in printdialog.properties
as suggested by bobj, you also need to define fontsize as well as fontcharset
and then call ::CreateFontIndirect(&logfont)
+   font = MS Sans Serif
+   fontsize = 8;
+   fontcharset = 0; 
Why fontcharset?  It's because you can't display the Japanese text with 
fontcharset=0 (ie. ANSI_CHARSET) for example.

If we just want to use the system font for the controls for now, then
/r=yokoyama on 05/31/01 11:08 with above (hFont != NULL) checking.

Comment 59

[Shanjian Li]

It seems to me that font name other than default_gui and default_system are not implemented yet. 
But I guess that is not necessary any way. The print dialog box is implemented through OS, so 
it has to and should be kept as consistent as rest of window dialog box. I did not spot any problem
except the null checking. But I would suggest someone try this on japanese windows system to 
make sure it works with both default_gui and default_system. (my source tree is outdated and I only 
have modem connection today.) Another suggestion is, why we want to leave hfont to be NULL for 
default_gui, can we just use GetStockObject(DEFAULT_GUI_FONT)? 

Comment 60

[rods (gone)]

Yes, I added that same check after the patch was made. 

I am trying to get around "not" having to specify a real font name because they 
differ from platform to platform ("MS Sans Serif" is probably not 
available on Linux). Unless we commonly have different "properties" files for 
each platform (which I doubt). I was hopefully we could make up some "generic" 
names like what I suggested that could/would translate to a platform specific 
font.

And yes, comments in the properties file as to what fonts are available would be 
a must. I could easily add the font size.

Comment 61

[rods (gone)]

As to shanjian comments, the idea of the printdialog is to always let it default  
back to the completely native case. I didn't want to assume the 
GetStockObject(DEFAULT_GUI_FONT) is the same as the font that is defined in the 
widget.rc file. So I let the default case be a no-op.

Comment 62

[bobj]

Shanjian,  Did Rod address your concerns?

Frank, Is Shanjian online?  (Shanjian is moving to a new house right now.)

Rod,
  Will you provide your updated patch with the externalization of the font size?

Roy or Naoki,  Will you try out the new patch on Ja Windows using
Maruyama-san's printdialog.properties?

We need to try this out ASAP, because Rod is heading off for sabbatical.

Comment 63

[rods (gone)]

Do we know for sure we need to be able to set the font size? 

I don't want to go to all the work of having to set the font size if it isn't 
absolutely necessary. LOGFONTs can be a pain to work with sometimes.

Comment 64

[Kevin McCluskey (gone)]

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

Comment 65

[nhottanscp]

Which patches should be applied?
I used printdialog.properties (05/24/01 11:40) and the patch (05/31/01 11:08),
still the same result as the screen shot (05/31/01 08:18).

Comment 66

[bobj]

> Which patches should be applied?
> I used printdialog.properties (05/24/01 11:40) and the patch (05/31/01 11:08),
> still the same result as the screen shot (05/31/01 08:18).

printdialog.properties (05/24/01 11:40) is the English version.  So I would
have expected to see English strings, not the screen shot from 05/31/01 08:18. 

You need to try the Japanese one from 05/27/01 06:08, 
    http://bugzilla.mozilla.org/showattachment.cgi?attach_id=36272

This Japanese printdialog.properties does not include a "font=xxx" entry, so
hfont will be set to NULL and the native dialog font should be used.
Right Rod?

Comment 67

[nhottanscp]

I actually used the Japanese one 05/27/01 06:08 (sorry I mentioned the wrong
attachment). I tried that on WinNT 4 JA.

Comment 68

[bobj]

Attachment: screenshot showing 8pt Japanese

Comment 69

[bobj]

> Do we know for sure we need to be able to set the font size? 
>
> I don't want to go to all the work of having to set the font size if it isn't 
> absolutely necessary. LOGFONTs can be a pain to work with sometimes.

I attached a hi-res jpeg showing Japanese text in 12, 10 and 8 point using
a MS font, MS-Gothic.  As you can see with at 8 pts the more intricate
characters start becoming blurred.  So, if we hardcode the size to 8 pts
in widget.rc, this may not be acceptable for Japanese (Chinese and Korean too).

Comment 70

[bobj]

> Which patches should be applied?
> I used printdialog.properties (05/24/01 11:40) and the patch (05/31/01 11:08),
> still the same result as the screen shot (05/31/01 08:18).

I think you need to apply the earlier patches as well.  The last patch only
seems to add the font stuff.  Here is the list I think you need:
 - 05/25/01 04:04  final patch with minor changes suggested by reviewers
 - 05/25/01 10:24  nsDeviceContext.h file changes
 - 05/27/01 06:08  printdialog.properties translated \uxxxx form
 - 05/31/01 11:08  patch for being able to specify the "system" font.

Rod, Is this correct?

Comment 71

[nhottanscp]

I got an error applying the last patch. Please attach a single patch which
contains all the required changes.

Comment 72

[nhottanscp]

I mean error applying the last patch (05/31/01 11:08) over the patch of 05/25/01
04:04.

Comment 73

[rods (gone)]

I applied the last patch (05/31/01 11:08) successfully to a fresh tip pull and 
build.

I worked with the fonts yesterday and didn't have much luck. I wrote new code to 
get the default GUI font and then create a new font with all the same settings 
(as an experiement) and when the new font was set into the dialog it was a 
different size and appeared "bold". So, of coarse then adding the ability to set 
the font size didn't have the expected results. If I was to allow the 
specification of several more font attrs (like name, weight, etc.) it would also 
mean having to somehow describe the char_set to create the proper font. Which I 
think takes us further down away from cross-platform.

I feel feel stuck at this moment.

Comment 74

[Roy Yokoyama]

adding yokoyama to cc list

Comment 75

[rods (gone)]

Attachment: new patch - augments native dialog

Comment 76

[rods (gone)]

Kevin's original idea for the solution for this bug was to augment/extend the 
native dialog. I miss understood how the print hook function worked and that 
coupled with not knowing the control IDs for the native dialog lead me down the 
other path (which gave me the knowledge for this solution).

So I have attached code where we are now ALWAYS using the native localized 
dialog and this new code enlarges the native dialog and adds the controls to it. 

The properties file is still used to localize the new controls. I am doing all 
my sizing and positioning based on "known" controls that are already in the 
dialog, so everything should be ok.

If somebody could apply this patch (against the tip) and test it out in Japanese 
and German that would be great.

Comment 77

[Roy Yokoyama]

Rod: I'll try the patch in Japanese Windows.

Comment 78

[Roy Yokoyama]

Attachment: Printdlg screen capture in W2K-Ja 1024x768

Comment 79

[rods (gone)]

What would be intersting if if someone could "escape-seq" the Japanese strings 
for the extra 3 labels and see if the display as Japanese.

Also I should probably not size the new group box the same as the one above it.

Comment 80

[Kevin McCluskey (gone)]

As a fallback PDT would like there to be an option to turn of the extra options
in the printdialog per language.

Comment 81

[Roy Yokoyama]

rods: you read my mind.  As a matter of fact, I was changing the properties file
to see if "escape-seq" Japanese strings can be displayed.  So far
they all showed up as "????".  Investigating....

Comment 82

[Roy Yokoyama]

Attachment: printdlg with "escape-seq" japanese string.

Comment 83

[Roy Yokoyama]

My bad.  I was setting my W2K-Ja to have the system default charset of Hebrew.
The printdlg with "escape-seq" japanese string works great!!

Comment 84

[Roy Yokoyama]

Attachment: Screen shot of printdlg in TRUE native Japanese OS

Comment 85

[rods (gone)]

Thank you Roy! This is great! I'll fix up the group box sizing code and get a 
patch ready for check in.

Comment 86

[rods (gone)]

Attachment: full patch for extending the native dialog

Comment 87

[Kevin McCluskey (gone)]

patch 37886 looks good. r=[e-mail]

Comment 88

[Frank Tang]

roy- please also test this patch under 
Japanese Win95/98/Me/NT4 Thanks. At least try one non NT platform today. That 
usuaully will show problem in this kind of area. 

Comment 89

[Roy Yokoyama]

ftang - I don't have Japanese W9x nor WinMe.  I have W2k-Ja, NT-e,  and W98CT.

Comment 90

[Yuying Long]

status filed in print dialog: on WinME-Ja,the string display as garbage.
                              on WinNT-Ja, there is nothing display in that field.

Comment 91

[rods (gone)]

In a nutshell, I am asking the dialog's native window handle for it's font and 
then setting that font into the new controls. I then use the GetACPString 
routine to convert the strings from the properties file to MultiByte.

So at this point, I need some localization person to tell me what to fix.

Yuying, which properties file did you use? The one Roy used or the english one 
which was part of the patch? Roy could yo attach your Japanese version to this 
bug, thanks.

Comment 92

[Roy Yokoyama]

rod: I used the file already attached to his bug.
05/27/01 06:08 printdialog.properties translated \uxxxx form   (text/plain) 

Comment 93

[rods (gone)]

05/27/01 06:08 printdialog.properties would not be correct for the current 
patch, I will attach something I think ought be correct.

Comment 94

[rods (gone)]

Attachment: Here is my try at the correct Japanese properties file for the current patch

Comment 95

[Marc Attinasi]

sr=attinasi for 
patch at http://bugzilla.mozilla.org/showattachment.cgi?attach_id=37886

Nice work Rod

Comment 96

[Kevin McCluskey (gone)]

r=[e-mail].

Comment 97

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 98

[rods (gone)]

fixed

Comment 99

[Roy Yokoyama]

Verified in FarEast Windows OS (W2K-Ja, Win98CT).  printdlg extension displays
nicely.

Comment 100

[sujay]

marking verified per Roy's comments.