Closed
Bug 78319
Opened 24 years ago
Closed 24 years ago
[FIX]Win32: issue of print dialog localization
Categories
(Core :: Printing: Output, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla0.9.2
People
(Reporter: masaki.katakai, Assigned: rods)
References
Details
(Keywords: intl, l12y)
Attachments
(21 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/plain
|
Details | |
(deleted),
image/jpeg
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
image/jpeg
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
image/jpeg
|
Details | |
(deleted),
image/jpeg
|
Details | |
(deleted),
image/jpeg
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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•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"
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.
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.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.2
Comment 5•24 years ago
|
||
Ray - can you comment on this please?
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•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)?
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)
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.
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.
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.
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.
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.
Assignee | ||
Comment 15•24 years ago
|
||
Assignee | ||
Comment 16•24 years ago
|
||
Assignee | ||
Comment 17•24 years ago
|
||
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)
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?
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.
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.
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.
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.
Comment 24•24 years ago
|
||
DanielMC - Can you help us out here???
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.
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.
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.
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
Comment 29•24 years ago
|
||
sorry Rose, I mean printdialog.dtd
Comment 30•24 years ago
|
||
Comment 31•24 years ago
|
||
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.
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.
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; } }
Assignee | ||
Comment 35•24 years ago
|
||
Assignee | ||
Comment 36•24 years ago
|
||
Assignee | ||
Comment 37•24 years ago
|
||
Assignee | ||
Comment 38•24 years ago
|
||
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
Comment 40•24 years ago
|
||
sr=waterson
Assignee | ||
Comment 41•24 years ago
|
||
Comment 42•24 years ago
|
||
Looks like this is cooked. Request that we try and move this to M0.9.1.
Priority: -- → P2
Comment 43•24 years ago
|
||
a=blizzard for 0.9.1
Comment 44•24 years ago
|
||
Comment 46•24 years ago
|
||
Don checked in the fix.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 47•24 years ago
|
||
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.
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.
Comment 50•24 years ago
|
||
Maruyama-san, Have you tried your Japanized printdialog.properties with a later build?
Comment 51•24 years ago
|
||
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.
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)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla0.9.1 → mozilla0.9.2
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.
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.
Status: REOPENED → ASSIGNED
Assignee | ||
Comment 56•24 years ago
|
||
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?
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.
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)?
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.
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.
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.
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.
Comment 64•24 years ago
|
||
*** Bug 69610 has been marked as a duplicate of this bug. ***
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).
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?
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.
Comment 68•24 years ago
|
||
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).
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?
Comment 71•24 years ago
|
||
I got an error applying the last patch. Please attach a single patch which contains all the required changes.
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.
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.
Comment 74•24 years ago
|
||
adding yokoyama to cc list
Assignee | ||
Comment 75•24 years ago
|
||
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.
Comment 77•24 years ago
|
||
Rod: I'll try the patch in Japanese Windows.
Comment 78•24 years ago
|
||
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.
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.
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....
Comment 82•24 years ago
|
||
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!!
Comment 84•24 years ago
|
||
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.
Assignee | ||
Comment 86•24 years ago
|
||
Comment 87•24 years ago
|
||
patch 37886 looks good. r=kmcclusk@netscape.com
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.
Comment 89•24 years ago
|
||
ftang - I don't have Japanese W9x nor WinMe. I have W2k-Ja, NT-e, and W98CT.
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.
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.
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)
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.
Assignee | ||
Comment 94•24 years ago
|
||
Comment 95•24 years ago
|
||
sr=attinasi for patch at http://bugzilla.mozilla.org/showattachment.cgi?attach_id=37886 Nice work Rod
Assignee | ||
Updated•24 years ago
|
Summary: Win32: issue of print dialog localization → [FIX]Win32: issue of print dialog localization
Comment 96•24 years ago
|
||
r=kmcclusk@netscape.com.
Comment 97•24 years ago
|
||
a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)
Blocks: 83989
Assignee | ||
Comment 98•24 years ago
|
||
fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 99•24 years ago
|
||
Verified in FarEast Windows OS (W2K-Ja, Win98CT). printdlg extension displays nicely.
You need to log in
before you can comment on or make changes to this bug.
Description
•