Beiträge von ITEC

When we use WPTools to produce HTML using the format "HTML-writespan" on Delphi 7 and WPTools V5.51. However, the colour of bullet points is discarded by the conversion and they will always be converted to black. They appear in the correct colour in the WPTools memo and HTML does support coloured bullet points. Is there a fix for this?

This works, thanks.

Am I right in thinking this was bug, specifically will this change be made in the next release?

The problem is that WPTools, has a bug where when the system locale is set to Japanese it does not encode CJK text with hex codes when saving to RTF. Presumably WPTools is comparing the current system locale to GetACP or CP_ACP under the assumption that this refers to 1252 or something along those lines.

But, to be clear, the problem is that WPTools produces corrupt RTF files when those files contain CJK text and are on a Japanese (and presumably others) system locale.

As this is a bug, an idea on when it will be fixed would be great!

So... um is this going to be fixed? Do you have any idea when? Or, shall I suggest they abandon the whole IT thing and use a paper and pen???

OK, it turns out that the reason it wasn't encoding the text is because my system locale (Language for non-Unicode programs) was set to Japanese (Japan). When I changed this back to English (United Kingdom) and rebooted it did start encoding the text correctly. This is not the correct behaviour, I would argue; the text should always be encoded regardless of the system locale.

The RTF actually does look OK in the WPTools MultiDemo and in Wordpad (in contradiction to what I said before) but in Word (2007 & 2010 at least) it does not appear correctly. If I open this WPT file in the multi demo and then save it as an RTF it does the same thing and saves it without encoding.

Well, that didn't help, for some reason WPRichEdit is not encoding the text, see the example below (original file). Notice that the Japanese text is not encoded and while it looks OK when looking at the RTF in notepad, it shows as mojibake in wordpad etc

{\rtf1\ansi\deff0\uc1\ansicpg932\deftab720{\fonttbl{\f0\fnil\fcharset1 Arial;}{\f1\fnil\fcharset2 Wingdings;}}{\colortbl\red0\green0\blue0;\red255\green0\blue0;\red0\green128\blue0;\red0\green0\blue255;\red255\green255\blue0;\red255\green0\blue255;\red128\green0\blue128;\red128\green0\blue0;\red0\green255\blue0;\red0\green255\blue255;\red0\green128\blue128;\red0\green0\blue128;\red255\green255\blue255;\red192\green192\blue192;\red128\green128\blue128;\red0\green0\blue0;}\wpprheadfoot1\paperw12240\paperh15840\margl1800\margr1800\margt1440\margb1440\headery254\footery254\endnhere\sectdefaultcl{\*\generator WPTools_5.500;}{\plain\fs32\cf3 This is the new (UK) mail to accounts template.\par
\plain\fs32\cf3 Applicant\par
\plain\fs32\cf3{\field{\*\fldinst{MERGEFIELD APPLICANT}}{\*\wpfldparam{APPLICANT}}{\fldrslt{Christian Mague}}}\par
\pard\plain\plain\fs32\cf3\par
\plain\fs32\cf3 Duration\par
\plain\fs32\cf3{\field{\*\fldinst{MERGEFIELD DURATION}}{\*\wpfldparam{DURATION}}{\fldrslt{長期}}}\par
\pard\plain\plain\fs32\cf3\par
\plain\fs32\cf3 Start Date                End Date\par
\plain\fs32\cf3{\field{\*\fldinst{MERGEFIELD START_DATE}}{\*\wpfldparam{START_DATE}}{\fldrslt{18-10-2004}}} to {\field{\*\fldinst{MERGEFIELD END_DATE}}{\*\wpfldparam{END_DATE}}{\fldrslt{29-3-2010}}}\par
\pard\plain\plain\fs32\cf3\par
\plain\fs32\cf3 Pay:PAY\par
\plain\fs32\cf3 Charge:{\field{\*\fldinst{MERGEFIELD CHARGE}}{\*\wpfldparam{CHARGE}}{\fldrslt{Fee : 25.00%}}}\par
\plain\fs32\cf3 Profit:{\field{\*\fldinst{MERGEFIELD PROFIT}}{\*\wpfldparam{PROFIT}}{\fldrslt{3125000.00}}}\par
\pard\plain\plain\fs32\cf3\par
\plain\fs32\cf3 EXP_DURATE: {\field{\*\fldinst{MERGEFIELD EXP_DURATE}}{\*\wpfldparam{EXP_DURATE}}{\fldrslt{長期}}}\par
\pard\plain\plain\fs32\cf3\par
\plain\fs32\cf3{\field{\*\fldinst{MERGEFIELD COMPANY}}{\*\wpfldparam{COMPANY}}{\fldrslt{Morgan Stanley}}}\par
\pard\plain\plain\fs32\cf3\par
\plain\fs32\cf3{\field{\*\fldinst{MERGEFIELD COMPANY_ADDRESS}}{\*\wpfldparam{COMPANY_ADDRESS}}{\fldrslt{}}}\par
\pard\plain\plain\fs32\cf3\par
\plain\fs32\cf3{\field{\*\fldinst{MERGEFIELD CONTACT}}{\*\wpfldparam{CONTACT}}{\fldrslt{Y. Hamasaki}}}\par
\pard\plain\plain\fs32\cf3\par
\pard\plain\plain\fs32\cf3\par
\plain\fs32\cf3 invoice details:\par
\pard\plain\plain\fs32\cf3\par
\plain\fs32\cf3{\field{\*\fldinst{MERGEFIELD INVOICE_ADDRESS}}{\*\wpfldparam{INVOICE_ADDRESS}}{\fldrslt{スタヴァンゲルはノルウェーの都市。ローガラン県の県都。人口は約11万2千人。}}}\par
\pard\plain\plain\fs32\cf3\par
\pard\plain\plain\fs32\cf3\par
}}

This is probably us misusing the component, but when we merge national text (Japanese) into a WPRichEdit and then save the memo to an RTF file, the memo does not encode the CP932 text in the normal RTF way, using escape codes and hex. Is there a specific requirement for this to work?

OK, I think I've made a bit progress, InsertWideString() appears to never handle the painting correctly, regardless of the language, as a workaround I have tried modifying WMIMEEndComposition()

procedure TWPCustomRtfEdit.WMIMEEndComposition(var Message: TMessage);
begin
  inherited;


  if Assigned(FMemo._EditBox) then
    FMemo._EditBox.Invalidate();
end;

This seems to solve problems inputting Japanese text, but I suspect it's not the preferred solution.

Any news on this? I really don't think its Japanese wrapping...

I don't think the Japanese word wrapping rules (which I think are called kinsoku shori) are the issue, they don't appear to apply to the text I've seen used. Also, I've tried typing a like 5 Japanese characters and then tried inserting a space and nothing appears until I select the text, it seems like an issue similar to the previous one I looked for help on.

There are two Japanese issues users are experiencing, the first is that if you type text in full size katakana and then try to insert a space, nothing happens until the text is repainted, i.e. you select the text where you expect the space to appear. All the spaces you typed will then appear.

Secondly, and I don't know if there is anything that can be done about this, if you copy Japanese text from a WPRichText memo and paste it into word, the encoding is not brought over and you get garbage mojibake. However, if you do a Paste Special in Word and choose "Unformatted Text" or "Unformatted Unicode Text" it does come over OK.

There is a third issue that I haven't actually been able to repeat yet (probably because I don't know how to type Japanese) but one that someone may recognise is that the Japanese users showed typing Japanese text on a line. The line began with katakana and ended with hiragana and some characters were invisible until the user hit Enter, there was a space where they were expected.

These problems also occur on the MultiDemo exe, which I think means it affects WPTools 6 as well. This is on Delphi 7 and WPTools 5.51.

From what I can tell, historically, Japanese was not supported because of specific line wrappings. However I am trying to enter Japanese text into WPRichText controls from WPTools 5. I can actually enter the text OK, but need to press the delete key approx 15 times before the text begins to delete.

Is there any way around this, or can this be fixed?

This is on Delphi 7 with WPTools 5.40.