Home General
New Blog Posts: Merging Reports - Part 1 and Part 2

Rich text - chr 173 vanishes in non-symbol fonts

edited December 2001 in General
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??

Comments

  • edited December 2001
    I can't seem to be able to enter it into our editor, a Delphi TRichEdit
    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


  • edited December 2001
    Hi Jim

    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
  • edited December 2001
    Ok, I get the dash character in the rtf, now. True, RB is using the same
    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


  • edited December 2001
    Hi Jim,

    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
  • edited December 2001

  • edited December 2001
    Bruce wrote

    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
  • edited December 2001
    Hi Jim,

    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
  • edited December 2001
    We don't perform anything special for this character. We totally rely on the
    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


  • edited December 2001
    OK, so Word uses the RichEd32.Dll somehow differently to Wordpad or maybe
    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
  • edited December 2001
    I loaded your rtf into a TRichEdit on a form and it showed up empty. Then I
    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


  • edited December 2001
    Thanks Jim for persevering with this.

    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
  • edited December 2001

  • edited December 2001

    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
  • edited December 2001

  • edited December 2001
    Thanks Bruce, knowing that at least one other developer can repeat the weird
    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
This discussion has been closed.