Rich text - chr 173 vanishes in non-symbol fonts
RB v6.02 D5
In preview of reports with a ppRichText control, any occurances of chr 173
in the rich text mysteriously vanish if the font is not a symbolic font.
You can see this behaviour in the rich text protery editor too. Open the
editor, choose a symbolic font e.g. symbol, insert chr 173 e.g. Alt+0173 and
you see an "up arrow". Now do the same with a non-symbolic font e.g. Arial
and you see a "little line" alot like a hyphen (chr 45). Save the changes.
Finally return to edit this text again. The chr 173 in Symbolic font is
still there, but in Arial it has gone.
This is a big problem for me as I am reporting text written using chr 173 in
a bespoke font as a significant character. Is there something special about
chr 173???? An RTF file with this character in shows in the standard
TRichEdit control.
Any ideas??
In preview of reports with a ppRichText control, any occurances of chr 173
in the rich text mysteriously vanish if the font is not a symbolic font.
You can see this behaviour in the rich text protery editor too. Open the
editor, choose a symbolic font e.g. symbol, insert chr 173 e.g. Alt+0173 and
you see an "up arrow". Now do the same with a non-symbolic font e.g. Arial
and you see a "little line" alot like a hyphen (chr 45). Save the changes.
Finally return to edit this text again. The chr 173 in Symbolic font is
still there, but in Arial it has gone.
This is a big problem for me as I am reporting text written using chr 173 in
a bespoke font as a significant character. Is there something special about
chr 173???? An RTF file with this character in shows in the standard
TRichEdit control.
Any ideas??
This discussion has been closed.
Comments
editor on a form, or even into WordPad. Maybe I'm not doing something
right? I never see a hypen looking line. It's always blank. If our rich
text control doesn't dispaly it on the page generation, then you may want to
look into replacing our default rich text engine, with one from Infopower or
WPTools.
----------------------------------------------
Article: ReportBuilder's RichText Architecture
----------------------------------------------
The RichText in ReportBuilder is a wrapper around Delphi's TRichEdit
which
in turn relies on Windows. There are two versions of Windows richedit -
RichEd32.dll is the older one and RichEd20.dll is a newer one (RichEd32
is being phased out). Delphi by default relies on RichEd32 - the older
version. To use some of the more advanced features of Windows RichEdit,
see the topic on InfoPower RichEdit Support below.
In general Windows RichEdit supports the type of formatting that you can
do using WordPad.
InfoPower RichEdit Support
---------------------------
InfoPower from Woll2Woll Software is a popular database add-on product
for Delphi. InfoPower's TwwRichEdit components support the Windows
RichEdit2 format. This format allows the rich text data to contain
embedded bitmaps and OLE objects. For more information please see
http:\\www.Woll2Woll.com.
ReportBuilder includes a component that enables the TppRichText and
TppDBRichText controls in ReportBuilder to use the formatting
capabilities of InfoPower's TwwRichEdit when rendering RTF data. The
ppWWRichEd.pas unit located in the ..\RBuilder\InfoPower directory
defines a TwwDBRichEdit descendant and then registers the class with
ReportBuilder. This enables the TppRichText and TppDBRichText controls
in ReportBuilder to use the formatting capabilities of TwwDBRichEidt
when rendering data.
WPTools Support
----------------
WPTools is a collection of components used to edit and print
formatted text. With its own RTF engine, WPTools offers
numerous features not supported by the standard Windows
RichEd20.dll. This control lets you use tables, paragraph
frames, headers and footers etc. Using the optional
ReportBuilder support units for WPTools 2.x, you can print
the enhanced WPTools features (justified text, tables, graphics
...) within your ReportBuilder reports.
For more information please see http:\\www.wptools.de.
--
Tech Support mailto:support@digital-metaphors.com
Digital Metaphors http://www.digital-metaphors.com
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com
Not sure why you were unable to repeat my problem, or quite what is
happening here. Could you have another look for me? I presume that RB is
using the same (basic) version of RichEdit as the Delphi TRichEdit control?
As chr 173 works with TRichEdit I don't think I need to replace the default
rich text engine.
Both Borland RichEdit example applications (textedit.exe and Richedit.exe)
show and save chr 173 along with all the other characters. These where
compiled with D5 in January. Are you saying this does not work for you?
Wordpad - yes you are right chr 173 does not appear in any font. Odd?
In the RB rich text property editor behaviour gets really odd: When I type
them in they appear, or when I open a RTF file with them in (\'ad is the
command), but when I save and reopen only those in symbol font are saved.
Is this something to do with versions of the RichEd DLL somehow?
Can you repeat this behaviour? Any ideas?
Sarah
rtf engine as the Delphi TRichEdit, ie. the RichEd.dll provided by Windows.
This is the rtf as created by typing into a Delphi TRichEdit on a form:
{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fcharset0
Arial;}{\f1\fnil Arial;}}
\viewkind4\uc1\pard\fs20\-
\par \f1
\par }
This is the rtf created from the rtf editor in RB (Delphi TRichEdit), when I
typed and saved Alt+0173:
{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fcharset0
Arial;}{\f1\fnil MS Sans Serif;}}
\viewkind4\uc1\pard\fs20\-\f1\fs16\par
}
This is the rtf as saved from typing Alt + 0173 in Wordpad:
{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset0
Arial;}}
\viewkind4\uc1\pard\f0\fs20\-\par
}
It looks like the dash is getting in the rtf in all three cases in an Arial
font setting. I'm not extremely familiar with rtf codes and control
charters as they are represented in rtf, but I guess this is right?
There is a font definition for the MS SansSerif, which I'm not sure how is
getting in there, since the only char in the editor is the Alt+0173 and it
had its font set to Arial 10. Perhaps that is causing a problem.
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com
Thanks for sticking with this, it is driving me nuts... the amazing
vanishing chr 173!!
I do have some familiarity with RTF codes having done my own reporting in
rich text before improving into RB I think you may have hit on the
problem. In RTF extended characters should be saved as \'nn where nn is the
hex of the character e.g. chr 173 would be \'ad. That this character is
being converted/interpreted as \'- could be it. Other extended characters
come out as \'nn.
So any ideas why Wordpad saves chr 173 as \'-, but for me both the TRichEdit
and RB property editor save it as \'ad (although for you it was as \'-)????
Also the RB property editor shows chr 173 if it is a Symbol font, but not
Arial, while the preview shows neither. Shall I send screen shots to show I
am not nuts?
This really does seem odd behaviour to me. And I am curious to be getting
different TRichEdit and property editor behaviour to you? Can't find
anything in the MSN Knowledgebase.
So still stuck with this. Why are we getting different behaviour?
Cheers
Sarah
Yes, I wondered that too - but it does not bode well for different users. My
versions are
Riched.Dll v4.00.834.839
Riched20.Dll v5.30.23.1200
Riched32.Dll v4.00.993.4
Any suggestions? I think it is the Riched.Dll that the D5 TRichEdit uses,
and so does RB?
I am also getting different RTF codes from Jim (if we are saving in the same
way?). He gets \'- saved for chr 173 while I get \'ad i.e. \'nn like all the
other extended characters. What do you get? Has MS changed the significance
of chr 173???
Thanks for taking an interest.
Sarah
Can you bear to look at some RTF with me Here I am entering a short
series of extended characters chr 170 to 176, in first Arial then Symbol
font
This is the rtf as created by typing into a Delphi TRichEdit on a form e.g.
richedit demo:
{\rtf1\ansi\deff0\deftab720{\fonttbl{\f0\fswiss MS Sans
Serif;}{\f1\froman\fcharset2 Symbol;}{\f2\fswiss\fcharset1
Arial;}{\f3\fswiss\fprq2 System;}{\f4\fswiss\fcharset1
Arial;}{\f5\froman\fcharset1 Symbol;}}
{\colortbl\red0\green0\blue0;}
\deflang2057\pard\plain\f2\fs16 \'aa\'ab\'ac\'ad\'ae\'af\'b0
\par \pard\plain\f5\fs16 \'aa\'ab\'ac\'ad\'ae\'af\'b0
\par \pard\plain\f2\fs16
\par }
I'm not too concerned by the list of fonts, but do note that chr 173 is
coded as \'ad
Typing in the RB Property editor and doing a Save As to file (before
anything else) gives:
{\rtf1\ansi\deff0\deftab720{\fonttbl{\f0\fswiss MS Sans
Serif;}{\f1\froman\fcharset2 Symbol;}{\f2\fswiss\fcharset1 Arial;}}
{\colortbl\red0\green0\blue0;}
\deflang1033\pard\plain\f2\fs16 \'aa\'ab\'ac\'ad\'ae\'af\'b0
\par \plain\f1\fs16 \'aa\'ab\'ac\'ad\'ae\'af\'b0
\par \plain\f2\fs16
\par }
Note all the characters are there and chr 173 coded as \'ad
Then save the rich text property, and re-open the property editor. For me
this does not show the Arial chr 173, but does show the Symbol chr 173.
Finally save this to a file from the property editor again. This gives
{\rtf1\ansi\deff0\deftab720{\fonttbl{\f0\fswiss MS Sans
Serif;}{\f1\froman\fcharset2 Symbol;}{\f2\fswiss\fcharset1
Arial;}{\f3\fswiss Arial;}{\f4\froman\fcharset2 Symbol;}}
{\colortbl\red0\green0\blue0;}
\deflang1033\pard\plain\f3\fs16 \'aa\'ab\'ac\'ae\'af\'b0
\par \plain\f4\fs16 \'aa\'ab\'ac\'ad\'ae\'af\'b0
\par \plain\f3\fs16
\par }
Note \'ad is now missing from the first (Arial) line of characters but there
for the second (Symbol font).
So it looks to me like both TRichEdit and the property editor deal with chr
173 as \'ad and show it. But when saved as a property some of the chr 173
characters are removed.
What is happening when saved as a property? Even more confusing you save chr
173 as \'- while I get \'ad, so why the differences?
Just to top it off Word 97 and Word 2000 happily handle chr 173, even though
Wordpad does not.
Anybody any ideas? Bruce suggests it could be DLL version problems, but
surely RB and TRichedit should be using the same DLL on my PC even if
different from yours and so behaving the same way.
Cheers
Sarah
behavior of Delphi's TRichEdit, and the different versions of the RichEd.dll
that exist. If Wordpad doesn't work, then that is not good news for us.
From what I understand, the RichEd.dll supports different standard levels of
rtf. I think Word is using the dll for a higher standard that the TRichEdit
or Wordpad, which is why it is working.
You may want to research using a 3rd party rich text component/engine, such
as WPTools. They have written their own rtf engine so that they do not have
to rely on this dll. They also sell an RB component which lets RB generate
rich text using the WPTools rtf engine.
http://www.wptools.de/html/wpreport.htm
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com
even not using that DLL...
But what I do not get is why if RB relies entirely on Delphi's TRichEdit
then why does chr 173 (just a special character - e.g. up-arrow in symbol
font) display in TRichEdit but vanish completely in RB report output, and
partly vanish in the property editor (depending on the font applied). Here
RB is not behaving like TRichEdit!!
And since this is all happening on my one PC I can not see how DLL version
differences could cause it?
So yes I can explore WPTools as you suggest, meanwhile is there any reason
why RB should behave differently from TRichEdit? Has Delphi changed the
TRichEdit in some way since D5?
Sorry to persist, but this is causing me big problems - and which character
will vanish next? So could you humor me wth one more attempt.
Stick the following RTF in a file and open it in a TRichEdit based editor
and it will show a line of up-arrows:
{\rtf1\ansi\deff0\deftab720{\fonttbl{\f0\fswiss MS Sans
Serif;}{\f1\froman\fcharset2 Symbol;}{\f2\froman\fcharset1
Symbol;}{\f3\fswiss\fcharset1 MS Sans Serif;}}
{\colortbl\red0\green0\blue0;}
\deflang2057\pard\plain\f2\fs16
\'ad\'ad\'ad\'ad\'ad\'ad\'ad\'ad\'ad\'ad\'ad\'ad\'ad\'ad\'ad\'ad\'ad\'ad\'ad
\'ad\'ad\'ad
\par }
Try to show this in a RB report and it appears empty.
Could you just tell me if using a simple Delphi TRichEdit based editor can
you see the arrows or not? I can. Then try looking at it in a report. That
is the crux of my problem.
Thanks
Sarah
loaded the same rtf file into Word, and I could see the arrows. This is
certainly strange, where you see the arrows in a TRichEdit, but not in a
Report rich text. I tried changing the charset in the rtf, but the symbols
still did not print in my TRichEdit, and at the same time, the arrows were
displayed in Word. I tried this rtf in both Delphi 5 and 6. I'll keep
researching this issue.
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com
So for you TRichEdit does not show chr 173 either, while that component (in
D5) always shows that character for me. Very strange indeed.
Could you email me an Exe example of a TRichEdit based editor that does not
show chr 173 for you, so I can try it here. Every TRichEdit I compile shows
them, and this might indicate if it is somehow a DLL version contributing.
Though with the other PCs that I have been able to try stuff on the
TRichEdit (in a complied app) happily shows this character.
I so hate it when you find differences in behaviour that you can't pin down.
How are we meant to develop reliable software that works for all users? I
suspect a Windows "feature" lurking somewhere. I develop under D5 (build
6.18) Update Pack 1. Am I the only developer that can see chr 173 in
TRichEdit??? A question I guess for a wider newsgroup.
Would it help if I sent you an example exe that does show chr 173??
Cheers
Sarah
Bruce said
I think that is probably true.
But what is worrying me is that TRichEdit does show chr 173 for me using D5
but not for Jim.
Am I the only one that can see chr 173 in TRichEdit???
Sarah
and inconsistent behaviour of chr 173 in TRichEdit, RB and other apps does
make me feel more sane What you describe is what I get.
I'm no nearer to finding a reason either, but still looking. I had not
thought to look at the RBAddOn rich text editor, but can not see anything
obvious in the RB source. I can not spot how RB is using the RichEd32.DLL
any differently to TRichEdit.
It is interesting that you sometimes can see this character in WordPad -
this is something I have never managed to do. I have also wondered about
regional settings having some effect, but not managed to identify anything.
The MSDN site is silent on this topic.
Robert Dunn has suggested that it could be to do with the default code page
of the RE control, but I don't know enough about RichEdit to pursue this.
Still looking for clues
Merry Xmas
Sarah