RichText fields not sizing correctly with Stretch

rbuser

We have had a few calls from users who have added RichText objects to their
templates but are losing the bottom line when printing...

It appears to only happen when STRETCH is enabled.

It also seems to be printer-specific - often just printing to another
printer will work OK. We have recreated it here printing to HP DeskJet 2000
and HP LaserJet 4000 - the DeskJet omits the bottom line but the LaserJet
prints it! Previewing on screen appears to work on both ...

I also suspect the font may have something to do with it - when we recreated
it here we were using TimesNewRoman...

Any suggestions?

I think I can send you an example if required ...

Regards,

Pete Colson

P.S. D6 & RB Ent 6.03

digitalmetaphors

The first thing to do is to make sure you have the latest printer drivers
for which ever printer you are using. The article below could give you some
useful tips on using RichText. You can also try using the InfoPower RichText
engine to see if that will eliminate the problem.

--
Cheers,

Alexander Kramnik
Digital Metaphors

----------------------------------------------
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.

A problem occurs when using the RichEd32 with Office 2000 installed and
trying
to print.

To correct this problem, we made a modification, to use RichEd20 when
possible.

Options:

1. You could try downloading a newer version of RichEd20 from MS web site.

2. You could try downloading the latest printer driver and testing with
another printer.

3. If you want to revert to the old RichText behavior, add an initialization
section to the bottom of your unit and code:


uses
ppDrwCmd;


initialization

ppRegisterRichEditClass(TRichEdit);


For an example of the above, check out ppDrwCmd.pas. It registers
a class called TppRichEdit:


initialization

ppRegisterRichEditClass(TppRichEdit);

rbuser

I have the converse problem: the last line of a rich text object being
duplicated on the following page. I get an extra page with just the line on
it, when it is already on the previous page.

Note: THE LATEST PRINTER DRIVERS HAVE BEEN DOWNLOADED and the behaviour
commen to a number of different printers (or at least in preview).

I had previously been told by RB, when I found rich text overflowing a
footer, that there is a problem when rendering a single line of rich text
containing multiple fonts:

"The problem arises when there is only one line of text with multiple fonts
scattered throughout. The RB RichText renderer relies on the Windows
Richtext renderer to wrap, measure, and fit the RichText. It seems that in
this situation only the font size of the last character is considered. So if
the font size of the last character is not the largest of all existant fonts
the text will overflow its parent because larger fonts are present."

I wonder if actually rendering of rich text is dodgy all round? Seems like
the measurement of what will fit on a page is going wrong in both our cases.

We could sit and blame the measuring on Windows, or curse the printer
drivers... But any sign of a fix????

Sarah

rbuser

Richtext has given me fits at times also.

Richtext at the bottom of a page would incorrectly cause RB to print an extra page.
For some reason, I found certain font sizes worked better in
RB than others. I finally just settled on a font size that seemed to behave best
in RB and didn't generate extra pages.

digitalmetaphors

I remember this bug from a year or so ago and it should have been fixed in
6.03. I have a QA case in which it fixed the problem, but there must be
another case which breaks it. There is no planned approach on the table at
this time. We will continue researching it. I've placed it on the bug
list.


Cheers,

Jim Bennett
Digital Metaphors

rbuser

Jim,
Sorry, but 6.03 does still have some kind of rich text measuring problem. I
suspect it is sensitive to font as Bill suggests. Problems also seem more
likely when the rich text has a variety of font sizes. This is what causes
me the problem anyway. If one font size/type would do then I would just use
a memo, but I need the variety that is why rich text! It is a real nuisance.


Would you like a simple example with the problem? Anything to encourage a
fix!

Sarah

digitalmetaphors

Sure, simple examples are good to have. If you have one then send it to
support@digital-metaphors.com and we'll see what we can do.


Cheers,

Jim Bennett
Digital Metaphors