Masaki Katakai Reporter
	Description • 24 years ago

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.

	Jaime Rodriguez, Jr.
	Comment 1 • 24 years ago

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"

	tao
	Comment 2 • 24 years ago

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.

	Kevin McCluskey (gone)
	Comment 3 • 24 years ago

Reassigning to Rod

	rods (gone) Assignee
	Comment 4 • 24 years ago

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.

	Michele Carlson
	Comment 5 • 24 years ago

Ray - can you comment on this please?

	Jaime Rodriguez, Jr.
	Comment 6 • 24 years ago

changing to nsbeta1-.

	rchen
	Comment 7 • 24 years ago

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+?

	Jaime Rodriguez, Jr.
	Comment 8 • 24 years ago

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)?

	Kevin McCluskey (gone)
	Comment 9 • 24 years ago

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)

	rchen
	Comment 10 • 24 years ago

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.

	Jaime Rodriguez, Jr.
	Comment 11 • 24 years ago

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.

	Kevin McCluskey (gone)
	Comment 12 • 24 years ago

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.

  

	rchen
	Comment 13 • 24 years ago

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

	bobj
	Comment 14 • 24 years ago

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.

	rods (gone) Assignee
	Comment 18 • 24 years ago

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)

	Jaime Rodriguez, Jr.
	Comment 19 • 24 years ago

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?

	rods (gone) Assignee
	Comment 20 • 24 years ago

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.

	rods (gone) Assignee
	Comment 21 • 24 years ago

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.

	bobj
	Comment 22 • 24 years ago

> 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.

	rods (gone) Assignee
	Comment 23 • 24 years ago

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.

	Jaime Rodriguez, Jr.
	Comment 24 • 24 years ago

DanielMC - Can you help us out here???

	bobj
	Comment 25 • 24 years ago

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.

	rchen
	Comment 26 • 24 years ago

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.

	rods (gone) Assignee
	Comment 27 • 24 years ago

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.

	danielmc
	Comment 28 • 24 years ago

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

	danielmc
	Comment 29 • 24 years ago

sorry Rose, I mean printdialog.dtd

	nhottanscp
	Comment 32 • 24 years ago

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.

	rchen
	Comment 33 • 24 years ago

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. 

	rods (gone) Assignee
	Comment 34 • 24 years ago

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;
  }
}

	Kevin McCluskey (gone)
	Comment 39 • 24 years ago

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=kmcclusk@netscape.com

	Chris Waterson
	Comment 40 • 24 years ago

sr=waterson

	Jaime Rodriguez, Jr.
	Comment 42 • 24 years ago

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

	Christopher Blizzard (:blizzard)
	Comment 43 • 24 years ago

a=blizzard for 0.9.1

	Kevin McCluskey (gone)
	Comment 45 • 24 years ago

Moving to mozilla0.9.1

	Kevin McCluskey (gone)
	Comment 46 • 24 years ago

Don checked in the fix.

	Tsukasa Maruyama
	Comment 48 • 24 years ago

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.

	bobj
	Comment 49 • 24 years ago

> 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.

	bobj
	Comment 50 • 24 years ago

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

	Tsukasa Maruyama
	Comment 52 • 24 years ago

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

	rods (gone) Assignee
	Comment 53 • 24 years ago

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)

	rchen
	Comment 54 • 24 years ago

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

	rods (gone) Assignee
	Comment 55 • 24 years ago

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.

	bobj
	Comment 57 • 24 years ago

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?

	Roy Yokoyama
	Comment 58 • 24 years ago

cc'ing shanjian@netscape.com

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.

	Shanjian Li
	Comment 59 • 24 years ago

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)? 

	rods (gone) Assignee
	Comment 60 • 24 years ago

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.

	rods (gone) Assignee
	Comment 61 • 24 years ago

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.

	bobj
	Comment 62 • 24 years ago

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.

	rods (gone) Assignee
	Comment 63 • 24 years ago

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.

	Kevin McCluskey (gone)
	Comment 64 • 24 years ago

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

	nhottanscp
	Comment 65 • 24 years ago

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).

	bobj
	Comment 66 • 24 years ago

> 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?

	nhottanscp
	Comment 67 • 24 years ago

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

	bobj
	Comment 69 • 24 years ago

> 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).

	bobj
	Comment 70 • 24 years ago

> 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?

	nhottanscp
	Comment 71 • 24 years ago

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

	nhottanscp
	Comment 72 • 24 years ago

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

	rods (gone) Assignee
	Comment 73 • 24 years ago

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.

	Roy Yokoyama
	Comment 74 • 24 years ago

adding yokoyama to cc list

	rods (gone) Assignee
	Comment 76 • 24 years ago

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.

	Roy Yokoyama
	Comment 77 • 24 years ago

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

	rods (gone) Assignee
	Comment 79 • 24 years ago

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.

	Kevin McCluskey (gone)
	Comment 80 • 24 years ago

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

	Roy Yokoyama
	Comment 81 • 24 years ago

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....

	Roy Yokoyama
	Comment 83 • 24 years ago

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!!

	rods (gone) Assignee
	Comment 85 • 24 years ago

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

	Kevin McCluskey (gone)
	Comment 87 • 24 years ago

patch 37886 looks good. r=kmcclusk@netscape.com

	Frank Tang
	Comment 88 • 24 years ago

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. 

	Roy Yokoyama
	Comment 89 • 24 years ago

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

	Yuying Long
	Comment 90 • 24 years ago

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

	rods (gone) Assignee
	Comment 91 • 24 years ago

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.

	Roy Yokoyama
	Comment 92 • 24 years ago

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

	rods (gone) Assignee
	Comment 93 • 24 years ago

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

	Marc Attinasi
	Comment 95 • 24 years ago

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

Nice work Rod

	Kevin McCluskey (gone)
	Comment 96 • 24 years ago

r=kmcclusk@netscape.com.

	Asa Dotzler [:asa]
	Comment 97 • 24 years ago

a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)

	rods (gone) Assignee
	Comment 98 • 24 years ago

fixed

	Roy Yokoyama
	Comment 99 • 24 years ago

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

	sujay
	Comment 100 • 24 years ago

marking verified per Roy's comments.