Ian's RTF Print goodie, pagination question...

Ian, or anyone who knows:

I want to print an RTF report directly from Dolphin.  I have previously been
printing it from Word.  I insert page breaks in the RTF as needed during the
generation of the report.  When I print from Ian's goodie my page breaks are
ignored.  Am I missing something or are rtf page breaks not supported?

Any ideas to get around this?  I suppose I could insert blank lines to
finish off the page, or break the document up into smaller documents.  Any
better ideas?

I am using a D4 version of the "IDB Printer" package in D5, I think it is
the latest version available.

Can anyone recommend a relatively simple, inexpensive RTF viewer/printer
ActiveX control?  The MS RTF control seems to be fairly limited (no tables,
lines, etc...).  I know I can shell out to WordPad / Write but I think their
formatting is rather limited as well, and I would prefer a more integrated
user experience.

Thanks,

Chris

Chris,

> I want to print an RTF report directly from Dolphin.  I have previously
> been printing it from Word.  I insert page breaks in the RTF as needed
> during the generation of the report.  When I print from Ian's goodie my
> page breaks are ignored.  Am I missing something or are rtf page breaks
> not supported?

I've just done some experimenting and it appears that the external procedure
that Dolphin uses to create a RichTextEdit (see RichTextEdit>>readRtfFrom:
&etc) makes a number of alterations to the rtf text it is streaming in.  One
of these alterations is, unfortunately, to remove all the page formatting.
I've just spent an hour or so trying to persuade a RichTextEdit to hold an
rtfString that does contain page formatting but failed miserably :-(

I'm not sure why the RTE makes these changes to the original rtfText.  It
may be down to Dolphin working to the lowest level RichEdit control (version
1 - version 4.1 is the latest available) and paging wasn't included in
that?.  There may also be a flag that controls this - I'm going to have
another check later..

> Any ideas to get around this?  I suppose I could insert blank lines to
> finish off the page, or break the document up into smaller documents.  Any
> better ideas?

How about putting a visible text marker where you want a page break to be
and then having a script that broke the file into sections (using these
markers as delimiters), removed the marker and then printed each section as
a separate RTE document.  This would have the advantage that sections that
occupied more than one page would still flow to multiple pages as normal.

I'll see if I can get the above working in a reasonable manner.

> I am using a D4 version of the "IDB Printer" package in D5, I think it is
> the latest version available.

There's a new version for D5 that includes a lot more - enhanced page setup
and print preview for example.  However, this is only tested on Windows XP,
2000 and NT and uses api enhancements that are only available on those
platforms.  I have got a patch that should enable most of the extras to work
on earlier versions of Windows but a) I can't test it myself and b) from
reports, it might be the cause of some memory leakage.

> Can anyone recommend a relatively simple, inexpensive RTF viewer/printer
> ActiveX control?  The MS RTF control seems to be fairly limited (no
> tables, lines, etc...).

The latest RichEdit controls have a lot more functionality see (watch the
formatting)

<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pl
atform/CommCtls/Common/Common.asp>

but integrating it into Dolphin would _not_ be an easy task.

Regards
    Ian

Ian, Chris,

I think the problem is something to do with the Windows emulation of version 1
of the control; there doesn't  eem to be any Dolphin code that is replacing
/page with /par.

In the spirit of randomly hacking around, I added a new subclass of
RichTextEdit that overrides the class-side #winClassName and #registerClass to
use 'RichEdit20A' and 'RichEdit20.dll' respectively.  Added a new View resource
to RichTextPresenter, and opened it up.  Cut-and-Pasted from a Wordpad instance
that had a page-break in it (which isn't visible under W2k, but is still there
and works for printing).  That pasted OK into the new presenter and the /break
was retained (as shown by sending #richText to the View).

Tried to do a print preview:

    p := RichTextPresenter show: 'RichEdit2 view'.
    IdePrinter default printPreview: p view.

I had to override RichTextEdit>>asPrintingRichTextEdit in my new View class to
use a temporary instance of its own class rather than a RichTextEdit.
(Incidentally why is it necessary to create a new instance ?)  It *almost*
worked.  It goes into an infinite loop in PrinterAbstract>>printPreviewSetup
when the range doesn't advance properly (haven't investigated why), but
<CTRL><Break>-ing out of that, and breaking out of the loop from the debugger,
allowed the print-preview to come up, and show the correct pages.  I admit that
it was a slight problem was that it thought there were several thousand pages
rather than just two...  (A count of how many times it went around the loop?).

I don't understand what Ian's doing with the printer stuff (ignorance of
Windows printing *is* bliss); but it looks as if it'd be possible to use the
new windows control with the existing code with a bit of hacking and without
too many problems.  I agree that replacing all uses of the control would be a
major bit of work, but it might be easy enough for Chris to get the
functionality he needs just to preview and print rich text with page breaks.

    -- chris

Chris,

> I think the problem is something to do with the Windows emulation of
> version 1 of the control; there doesn't  eem to be any Dolphin code
> that is replacing /page with /par.

It's removed as a by product of RichTextEdit>>readTextFrom:format: where the
contents of the "gettableStream" is a fully featured rtfString but the
resulting streamedIn rtfSting has a lot of components, /page for example,
missing.

> In the spirit of randomly hacking around,

What other way is there :-)

[snip]
> I had to override RichTextEdit>>asPrintingRichTextEdit in my new View
> class to use a temporary instance of its own class rather than a
> RichTextEdit.(Incidentally why is it necessary to create a new instance ?)

A Printer subclass can be made to change the attributes of the RTE
(standardise font or make monochrome for example).  It could be a bit
awkward undoing these changes to the original RTE so, coupled with the fact
that an new RTE needs to be created for printing Strings and TextEdits
anyway, it seems easier to use a separate RTE in all cases.

> I don't understand what Ian's doing with the printer stuff (ignorance of
> Windows printing *is* bliss); but it looks as if it'd be possible to use
> the new windows control with the existing code with a bit of hacking
> and without too many problems.  I agree that replacing all uses of
> the control would be a major bit of work, but it might be easy enough
> for Chris to get the functionality he needs just to preview and print
> rich text with page breaks.

Hmmm. I was only thinking about replacing the entire RTE package but I can
see that just using the newer controls for printing might work. Time for a
bit of random hacking about myself...

I was also wondering how many changes would be needed to the basic image to
make the newer RTE usable.  The image itself wouldn't need to be updated to
use the extra functionality but at least it could be available for add-ons.

Ian

Chris,

> I had to override RichTextEdit>>asPrintingRichTextEdit in my new View
> class to use a temporary instance of its own class rather than a
> RichTextEdit. (Incidentally why is it necessary to create a new instance
> ?) It *almost* worked.  It goes into an infinite loop in
> PrinterAbstract>>printPreviewSetup
> when the range doesn't advance properly (haven't investigated why),

It appears that converting a rtfText to plainText results in a FormFeed
character (ACSII 12) being added for each page break.  I count these as
characters but the RichEdit printing routine just ignores them - the result
being that I think there's more to print than Windows does. Not a good idea!

This cures the problem but there may be a better way.

PrinterAbstract>>rangeFor: aRichTextEdit
    | text |
    text := ((printDlgStruct flags anyMask: PD_SELECTION)
            and: [aRichTextEdit hasSelection])
        ifTrue: [aRichTextEdit selection]
        ifFalse: [aRichTextEdit plainText].
    ^0 to: (text copyWithout: 12 asCharacter) size

As you pointed out, workspace testing shows that it is possible to use a
later version of the RTE control in a stand alone mode so one off
applications should be quite possible.  It will, I think, be a bit difficult
to integrate it into the current image, even as an addition, in any useful
way though.  The minute you go through an existing RTE any extra information
in the rtfText is lost.

Ian

Wrong!  It's not the form feeds but the line feeds that cause the problem.
I just happened to have the same number of each in both my pieces of test
text <sigh>.

Change the 12 asCharacter in the above to 10 asCharacter (or Character lf)
and it should cure the multiple page problem for all rtf texts.  This makes
a lot more sense as one of the differences between RichEdit 1 and subsequent
versions was the use of cr rather than cr-lf.

Ian

Ian Bartholomew <[hidden email]> wrote in message
news:BuWz9.3468$XN5.498607@wards...
> > It appears that converting a rtfText to plainText results in a FormFeed
> > character (ACSII 12) being added for each page break.  I count these as
> > characters but the RichEdit printing routine just ignores them - the
> > result being that I think there's more to print than Windows does. Not a
> > good idea!
> >
> > This cures the problem but there may be a better way.

Chris and Ian: Thank you so much!  You have saved me a lot of frustration.
Using the new RichEdit control with your changes does exactly what I want.
Once again c.l.s.d saves the day. ;)

Ian: I downloaded the new Dolphin XP print goodie, it is very impressive (as
are all your goodies, I really appreciate them).  I think I missed it
because it is not listed on the web page or in the documentation for the XP
goodies, but is for D4.  I just assumed the XP version was not publicly
released yet.

I would like to get a copy of the Printer backward compatibility patch if I
can.  I have an ME machine I can test it on.  Can you e-mail (my e-mail
address is valid) it or post it or a link here?

Much thanks,

Chris