Click here to Skip to main content
14,208,035 members
Rate this:
 
Please Sign up or sign in to vote.
See more:
Dear Experts

Not a programming question, more a technical Problem.

I have a legacy application (background process) that does not support Unicode. So to print documents in Chinese language I setup region settings “Language for non-Unicode programs” of W2012R2 to use “Chinese (Simplified, China)”.

So far so good, in case I start this app from my account (Session ID = 1) everything works fine.
The problem is, in case I start the app by my service (then app runs under Session ID = 0) then all Chinese characters are displayed as squares (which usually does means we have a font problem).

Does anybody can give me a hint what I’m missing?

Thank you very much in advance
Bruno

What I have tried:

Unsuccessful search in Google for an solution
Posted
Updated 10-Jun-16 9:54am
Rate this: bad
 
good
Please Sign up or sign in to vote.

Solution 1

This is a very unpleasant problem, but, most likely, not hard to solve. I would start it from the detection of what is that encoding. I don't know which one is the most likely, but I know quite a few ones for Chinese, Simplified or Traditional. Based on that information, you may start looking for a font, which is a separate problem, but it would be much safer to perform appropriate trans-coding, even if you have to do it on the fly.

If I had a text file with the text, I would find out the text's encoding pretty quickly, only if some obsolete standard is used; there aren't too many of them. May I ask you: did the legacy code work on some old Microsoft system, or is it something else. Old Microsoft encodings were based on "code page", which would accelerate search.

So, the detection methods which lies on the surface is using some modern Web browser. Put the fragment of text in a file ("ANSI") as is and open it in the browser. Usually, the browser's menu, something like View => Character Encoding => Auto-Detect => (…specify the language) gives you the result; if not, try non-auto.

If the encoding was covered by one or another "codepage" number, you can do a comprehensive search. For this purpose, you would need an editor which supports "ANSI" (actually, it used to be not really standard "extended ASCII", which still can be used) and "codepage". Frankly, I don't know where you get such editor at this moment. I just developed one myself. In worst case, keep in mind that I can share my source code, but it's fully functional on Windows, doesn't work as multi-platform yet; this is the only reason it's not published. I used Free Pascal and Lazarus LCL library, where they use their own, very unusual cross-platform way supporting of various encoding. The idea is: they don't support "Unicode" as most OS do, via UTF-16. Instead, internal representation is UTF-8, which is "Unicode-agnostic". The strings are considered as "ANSI strings", and "Unicode bytes" of UTF-8 multi-byte characters are considered as separate characters. Most string functions, where you don't need to select a sub-string with known number of characters, can work without knowing if it is Unicode or not. Now, the most interesting thing. The general-case string is "ANSI with codepage", where code page is the part of each string metadata, located in a string structure in the same way as its length. LCL text component render non-Unicode ANSI strings accordingly.

One product I know is Double Commander (its embedded "F4" editor), but it has fixed set of code pages. Going to source code can quickly solve this problem; the project is, of course, open sours (and highly recommended, by the way):
Double Commander — Wikipedia, the free encyclopedia,
Double Commander home page.

Another approach is: you can get a sample of the Chinese code as raw data, bytes, pack it with base64 and publish that base64 text in your question. I'll quickly determine the encoding for you.

If you know the encoding, writing a function which converts the array of bytes into a Unicode string won't be a big problem.

—SA
   
Comments
0x01AA 9-Jun-16 12:00pm
   
Dear Sergey
First of all thank you very much for your time and you detailed answers. I Need some time to go through all this Information.

The really strange Thing is, on W8.1 everything works fine (printing from the application as well as from Service) but on a W2012R2 Server Application Printout is ok, but printing from Service is not ok (squares). For me it Looks more like 2012 does "not know" the System locales in session 0.

Anyway thanks again, I will go through your answer and try step by step.

Kind regards
Bruno
   
You are very welcome, Bruno.
Yes, I understand that it looks weird, but who knows what weird peculiarities all those legacy programs, probably created much earlier than those OS versions, would have? I would suggest that your real goals should be to isolate this non-Unicode text by transcoding it to Unicode by the moment of time when it hits the screen. To start with, make sure that Unicode-based Chinese text is rendered correctly on the systems you use...
—SA
0x01AA 10-Jun-16 12:44pm
   
Hello Sergey
Step by step I followed some of your hints and made tests. My results:
- CodePage= 936 (like expected)
- MultiByteToWideChar does return correct and same result for App and also Service. This either with explicit codepage selection “936” and also with windows constant CP_ACP (the system default Windows ANSI code page).

Conclusion (at the moment): Fonts are the problem with the service

Now, either I find a solution with the font for service or I have to dive into the deep of QuickReport :(

A 5 of course and accepted.
Kind regards
Bruno

Sergey Alexandrovich Kryukov 10-Jun-16 12:55pm
   
All right, thank you.
I did not get one detail: suppose your trans-code CP 936 to Unicode. Will the text render with existing fonts in a Windows Unicode application? It should, because Chinese Simplified should be supported by all system by default. Just one of the common-use fonts would do. (Some fonts won't of course.)
—SA
0x01AA 10-Jun-16 14:29pm
   
"Will the text render with existing fonts in a Windows Unicode application?": Yes it does. E.g. Notepad does show/render it correctly and what I know, Notepad is a Unicode Application. For this I trans-coded "·ÖÉ¢ºì" and got "分散红" and wrote the result into a file.
Bruno
Sergey Alexandrovich Kryukov 10-Jun-16 14:37pm
   
So, does it mean that the problem is solved? Or do you need to automate it all somehow? Or any other problems?
—SA
0x01AA 10-Jun-16 15:03pm
   
No, unfortunatelly the Problem is not yet solved.

I think, you know Delphi very good. This legacy app is programmed with bcb6 (c++ Version of Delphi 6). And the Printer Report (which makes the Problem when executed in Session 0, Service) is using QuickReport. So I have to find, why Session 0 does not print well.

My hope at the Moment is: I tested always with "W2012R2 - US Language" with respective Settings for "non Unicode Apps". Now I'm waiting for the tests from my Chinese colleagues to know wheter same Problem happens on _real_ Chinese installations.

If everything works fine with _pure_ Chinese OS Setup, I'm a Little bit out of fire.

Thank you very much for your time.
Bruno
Sergey Alexandrovich Kryukov 10-Jun-16 15:45pm
   
I gave your the old Deplhi solution, and it was done on Delphi 6, which was not Unicode. But, If I'm not much mistaken, you don't have the source code, then you have nothing to fix or upgrade. Also, maybe I've been confused (or forgot): does this application send image right to the printer? (I was talking about on-screen rendering, maybe mistakenly...)

You are right, it might work Chinese settings of the OS, but do they have that old OS, in case it's needed. Anyway, make sure you try. There are other options. First is virtual PC. Also, I heard of applications solving such problem as "running an application on required code page".

I'm afraid that, even if you find on-a-pinch solution, without having the source code, this solution won't survive much longer. It may take as much as development of a new application from scratch.

—SA
0x01AA 10-Jun-16 16:16pm
   
"(I was talking about on-screen rendering, maybe mistakenly...)":
Yes, something mistakenly, my Problem is only for printouts done by a Windows service. Rendering on Screen works perfect. Anyway your hints gave me good Inputs what basics I need to check/clarify.

".... but do they have that old OS":
There is no need of an old OS. Everything (expect printing from a Service) works perfect also in latest OS like W2012R2.

Bruno


Sergey Alexandrovich Kryukov 10-Jun-16 19:52pm
   
I see, thank you for the note. Perhaps, yes, if suitable Chinese OS setup works, it may get a bit out of fire...
—SA
Sergey Alexandrovich Kryukov 10-Jun-16 16:00pm
   
See also Solution 2.
—SA
0x01AA 17-Jun-16 19:09pm
   
Hello Sergey
A Feedback from my side: Finally I recognized, that all the Problems came from different "font fallback" between app and Service.
Thank you for your time.
Bruno
Sergey Alexandrovich Kryukov 17-Jun-16 19:25pm
   
Understood. You are very welcome. Did you come to some final solution?
—SA
0x01AA 17-Jun-16 20:03pm
   
Not really a solution, more a (not nice, horrible...) Workaround. I recognized, that as soon as there is is a printable "TQRCustomLabel" with font Name "Default" then "font fallback" works for Services as it does for apps.

Bruno
Sergey Alexandrovich Kryukov 17-Jun-16 20:10pm
   
Well, how would you expect a real solution? Only via getting rid of legacy. We can talk only of a workaround. As to the service... it is still an application...
—SA
0x01AA 17-Jun-16 20:18pm
   
Dear Sergey
I don't think (I'm convinced at the Moment...) that it is _not_ "a legacy" problem. It is more the lack of my knowledge (based on bad documentation of MS) when/who/how "font fallback" does happen. This on really low Level like "TextOut" incl. all ex Versions of it.

And yes the Service is still an app (process), but the big difference seems to be the session....
Bruno

... sorry for These frequent corrections...
Bruno
Sergey Alexandrovich Kryukov 17-Jun-16 20:28pm
   
By "legacy problem" I mean your need to use some obsolete application without having its source code. You should agree that, without this application, the problem would not even exist.

Yes, I do understand that the fallback for fonts exist, but don't know the detail; probably this aspect is poorly documented (in contrast to something standard, such as CSS).

—SA
0x01AA 17-Jun-16 20:36pm
   
Basically it was _only my_ mistake not to recognize that the Problem was caused "only" by "failed font fallback".

After all this and if I'm start thinking in Details about it my brain blows up. How Web handle this? Yes CSS, but what happens if dest can not render....

Thank you again so much for your Patience and guidelines.
Bruno
   
I think you are right about CSS (the browser). In this respect, it behaves more reasonably. But of course, you can always come to characters rendered as boxes.
—SA
0x01AA 17-Jun-16 21:10pm
   
While googling for "my Problem" I recognized, that also with CSS vs. font fallback, there are a lot of questions/uncertainties.

Actually I am something ashamed, thinking about such things in detail only now...
Bruno
Rate this: bad
 
good
Please Sign up or sign in to vote.

Solution 2

After the discussion over Solution 1 (please see):

Now when we know the original code page, one possible work-around could be using Microsoft AppLocale utility:
AppLocale — Wikipedia, the free encyclopedia,
http://ntu.csie.org/~piaip/papploc.msi,
Microsoft AppLocale 1.3 Download (Free) — AppLoc.exe.

As you can see, it require a work-around for the Windows versions later than XP: Workaround to Install Microsoft AppLocale Utility in Windows Vista — Tech Journey.

Some replacements: Applocale Alternatives and Similar Software — AlternativeTo.net.

Also, it's claimed that this "clone" should work on XP to Windows 8: SBAppLocale — www.SteelBytes.com.

And also it's always possible to run the legacy thingy on a virtual machine, such as VirtualPC. You can set up a target virtual machine to required code page, or set it to XP and use AppLocale on it.

—SA
   
v3
Comments
0x01AA 10-Jun-16 16:18pm
   
Thank you, I know this "AppLoc.exe", but don't like it.
Bruno
Sergey Alexandrovich Kryukov 10-Jun-16 19:51pm
   
Thank you for the note. I can understand you very well; it's just that I like your situation when you are left with legacy without source code even less than AppLocale... :-) :-(
—SA
0x01AA 22-Aug-16 6:26am
   
Only a test: Try :java: :-)

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



Advertise | Privacy | Cookies | Terms of Service
Web01 | 2.8.190612.1 | Last Updated 10 Jun 2016
Copyright © CodeProject, 1999-2019
All Rights Reserved.
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100