Supporting Asia Pacific languages

[nc1264]

Will VPE support Asian Pacific languages as RTF (double byte)?
If not, will a UniCode version see the light of day. Now that you are moving into DotNet area this should become relevant to you. In DotNet it is more common to do things with Unicode and not RTF.

I have an application that is in desperate need to support Chinese etc. We can enter the text with RTF in our application but VPE35EntEd has problems to display it making it very difficult for us to move further.

[IDEAL Software Support]

> Will VPE support Asian Pacific languages as RTF (double byte)?

No.

> If not, will a UniCode version see the light of day.

We plan to create a Unicode version, but at present we can not give a date of implementation or release.

Regards
Thorsten Radde
IDEAL Software GmbH

[martin]

Well a few months later (and seeing some preparating by changed datatypes) can you now make any statement when we can expect a Unicode enabled version of VPE?

As you saw from another posting we are about the start using VPE in our projects but not having Unicode is a BIG pain!

VPE is a really great product but lacking Unicode might render it useless for us. For sure if we cannot solve our Slovenian problem in an acceptable way. Forcing people to have the appropriate system locale cannot be considered an acceptable way.

Regards,
Martin

[IDEAL Software Support]

A Unicode version will not be sooner released than in about 1.5 years from now.

[nc1264]

Martin,

why is supporting Slovanian a big pain. We handle many languages with RTF and VPE has no problem is printing them.
By using RTF there is no need to fiddle around with any system locale and it works like a charm. I can point you towards our website where we generate pdf's by using RTF text that is rendered by VPE without any problems at all.

The only languages giving problems with RTF are Asia Pacific ones......

Regards,

Ron

[martin]

Are you using the .NET version?

I cannot see how RTF would solve this issue. RTF is nothing else then text with some formatting information (correct me if I am wrong) so it should be affected by the same codepage problems that we face with plain text.

Anyway we have a solution now which works well for us and doesn't limit us to RTF - I wouldn't like to have to convert every data that we need to print into RTF anyway - converting it into the correct codepage seems much more natural.

Still I think the issue about codepages should be solved in the .NET layer of VPE itself plus speeding up Unicode development should be a high priority for VPE. Actually I think such a great product shouldn't risk not being seen as a viable solution in the .NET space just because it doesn't support Unicode. Trust me, I understand the effort that it takes to make such a product Unicode enabled if it hadn't been written with Unicode in mind but still - its a must have. Not because of Slovenian but generally to free all developers of even having to think about this problems that we faced.

[IDEAL Software Support]

>>
I cannot see how RTF would solve this issue. RTF is nothing else then text with some formatting information (correct me if I am wrong) so it should be affected by the same codepage problems that we face with plain text.
<<

This is not correct. You can specify the charset within the rich text (keyword "fcharset"). I want to thank Ron for his hint on that.

>>
Anyway we have a solution now which works well for us
<<

Can you explain the solution you are using? Or is it the code you sent us? The responsible programmer is currently checking it.

>>
Still I think the issue about codepages should be solved in the .NET layer of VPE itself plus speeding up Unicode development should be a high priority for VPE.
<<

The issue about codepages will be fixed ASAP.

Regarding Unicode: yes, well... each customer has its own view of what should be the next major enhancement of VPE. We agree that Unicode support is very important, but we are currently working very hard on other major enhancements of VPE and dycodoc - and it will take about 12 months until this work is finished. Then there is another major enhancement of VPE planned (cannot talk about it yet, sorry) and then finally we will come to the Unicode port.

The difficulty of the unicode port is not the internal character handling (16-bit), most of this work has already been done, the problem is the drawing of unicode strings. Things like right-to-left layout have to be supported as well as multi-character composition, i.e. in some languages two or more characters form a new single character. We know that Microsoft provides the uniscribe library for such a task, but we don't want to have this part of our code platform dependent. So the implementation of full unicode support is a big task, which has to be handled carefully.

[martin]

>>
I cannot see how RTF would solve this issue. RTF is nothing else then text with some formatting information (correct me if I am wrong) so it should be affected by the same codepage problems that we face with plain text.
<<

This is not correct. You can specify the charset within the rich text (keyword "fcharset"). I want to thank Ron for his hint on that.

This wouldn't solve the problem with the .NET layer. This layer doesn't even know that its RTF and wouldn't care about this keyword at all. The chars would still be converted using the wrong codepage.

>>
Anyway we have a solution now which works well for us
<<

Can you explain the solution you are using? Or is it the code you sent us? The responsible programmer is currently checking it.

Not 1:1 but using the exactly same approach.

>>
Still I think the issue about codepages should be solved in the .NET layer of VPE itself plus speeding up Unicode development should be a high priority for VPE.
<<

The issue about codepages will be fixed ASAP.

GREAT!

Regarding Unicode: yes, well... each customer has its own view of what should be the next major enhancement of VPE. We agree that Unicode support is very important, but we are currently working very hard on other major enhancements of VPE and dycodoc - and it will take about 12 months until this work is finished. Then there is another major enhancement of VPE planned (cannot talk about it yet, sorry) and then finally we will come to the Unicode port.

The difficulty of the unicode port is not the internal character handling (16-bit), most of this work has already been done, the problem is the drawing of unicode strings. Things like right-to-left layout have to be supported as well as multi-character composition, i.e. in some languages two or more characters form a new single character. We know that Microsoft provides the uniscribe library for such a task, but we don't want to have this part of our code platform dependent. So the implementation of full unicode support is a big task, which has to be handled carefully.

I understand but still its a hard pill to swallow to not have UNICODE support for printing. Sure we can workaround many of the issues that this imposes using the CharSet approach but will its nothing more then a workaround in times of .NET which is completely based on UNICODE.

[IDEAL Software Support]

This wouldn't solve the problem with the .NET layer. This layer doesn't even know that its RTF and wouldn't care about this keyword at all. The chars would still be converted using the wrong codepage.

This is not correct. The codepage selection is an RTF instruction within your text. The .NET environment will not convert it, VPE will convert it internally. So this works.