Printing RTF contents
satish_elnet@mail.cswl.com
Tuesday, July 16, 1996
I am using VC++4.0 and my application runs on Win95/WinNT/Win32s. My
Application generates a RTF file which contains shadings, highlighted
text and tables. I have serious problems in printing this RTF file.
I am listing out the problems i faced in my approaches...
RTF Control - This however doesnot support tables and shadings.
OleAutomation - Using Ole automation i can print the RTF file using MS
Word. But i cannot force all my customers to have
MS Word loaded in their machine.
WordViewer Control - This control provided by microsoft however
doesnot open all its functions to the user.
Is there any method for printing this RTF file? Can someone help me?
======================================================================
Satish Kumar.V.L satish_elnet@cswl.com
California Softwares Ltd. satish@cswl.com
Mike Blaszczak -- mikeblas@msn.com
Sunday, July 21, 1996
You've outlined the options available to you: if you think none of them are
acceptable for your application, you'll need to do something else. You can
either: investigate RTF-supporting libraries from third parties, or change
your application so that it manages data in a different format and you do the
painting and printing yourself.
It's hard for me to understand why you would generate an RTF file when your
users don't have Word for Windows. Maybe it turns out that you know they have
_some_ word processor that can deal with RTF. Maybe you should make your
program adaptive--so that it figures out what software is installed and drives
that word processing package appropriately. It's hard for me to guess about
which approach would be more appropriate for you because I can't readily
understand your needs: you need to find some third-party package which would
what _you_ want.
There have been rumblings, by the way, that the next version of Windows may
have enhanced common controls--and that might mean that the next version of
the RTF control will offer more vigorous support than the current version.
.B ekiM
http://www.nwlink.com/~mikeblas
----------
From: owner-mfc-l@netcom.com on behalf of satish_elnet@mail.cswl.com
Sent: Tuesday, July 16, 1996 3:24 PM
To: mfc-l@netcom.com
Subject: Printing RTF contents
I am using VC++4.0 and my application runs on Win95/WinNT/Win32s. My
Application generates a RTF file which contains shadings, highlighted
text and tables. I have serious problems in printing this RTF file.
I am listing out the problems i faced in my approaches...
RTF Control - This however doesnot support tables and shadings.
OleAutomation - Using Ole automation i can print the RTF file using MS
Word. But i cannot force all my customers to have
MS Word loaded in their machine.
WordViewer Control - This control provided by microsoft however
doesnot open all its functions to the user.
Is there any method for printing this RTF file? Can someone help me?
======================================================================
Satish Kumar.V.L satish_elnet@cswl.com
California Softwares Ltd. satish@cswl.com
Dave Kolb -- sasdxk@unx.sas.com
Tuesday, July 23, 1996
> From: Mike Blaszczak
> To: mfc-l@netcom.com
> Subject: RE: Printing RTF contents
> Date: Saturday, July 20, 1996 8:37 PM
>
...
>
> It's hard for me to understand why you would generate an RTF file when
your
> users don't have Word for Windows. Maybe it turns out that you know they
have
> _some_ word processor that can deal with RTF. Maybe you should make
your
> program adaptive--so that it figures out what software is installed and
drives
> that word processing package appropriately. It's hard for me to guess
about
> which approach would be more appropriate for you because I can't readily
> understand your needs: you need to find some third-party package which
would
> what _you_ want.
Mike,
One good reason to want good RTF support is to take have a text display
"richer" than plain text in your VC++ application. That's the whole idea
right behind the common controls is to allow C++/MFC apps to get advanced
functionality they don't have to code from scratch right? Word should not
be the only app that can create/view RTF files. Word docs are no longer
RTF anyway - at least not standard RTF. In fact (another
complaint/suggestion here) Word 95 won't even create Write (.wri) docs
anymore (an RTF of sorts) and Write format is the ONLY non plain (rich)
text doc format that can be viewed by all win32 systems using default OS
applications (e.g. Wordpad or Write). Yes, there is Wordview for .doc
files but most user's don't have it. Actually, everyone can read .wri docs
OK but I can no longer create them with Word 95. Even MSFT still supplies
a lot of readme files in .wri format. Would be nice if the RTF common
control read, displayed, printed and previewed .wri files and well as .rtf
files well. These features would make MFC all that more valuable for
creating rich text based apps.
> There have been rumblings, by the way, that the next version of Windows
may
> have enhanced common controls--and that might mean that the next version
of
> the RTF control will offer more vigorous support than the current
version.
I actually got riched20.dll and the new RichEdit2A (I think - see MSJ
Prosise's article on NT 4.0) window class in conjunction with
CRichEditView (4.1) to read an .RTF file doing some debug window class
editing and having loaded the dll library ahead of time but this control
did not display the text real well yet or fix the print preview problem
that comctl32.dll has.
It would be REALLY nice if a MSFT RTF common control had a bit more
enhanced RTF funtionality especially in the print preview area where the
current control via CRichEditView has some real problems dropping words.
This is a really cool common control but needs some more work on it.
Mike, Could you pass this on to whomever appropriate at MSFT? Calling the
WISH line (which I did) seems unlikely to carry the weight your suggestion
might.
P.S. Wordpad has this same print preview bug at some (but not all) screen
resolutions.
Thanks,
Dave Kolb
SAS Institute
919-677-8000 x6827
----------
Mike Blaszczak -- mikeblas@msn.com
Friday, July 26, 1996
From: owner-mfc-l@netcom.com on behalf of David Kolb
Mike,
> One good reason to want good RTF support is to take have a text display
> "richer" than plain text in your VC++ application.
> That's the whole idea
> right behind the common controls is to allow C++/MFC apps to get advanced
> functionality they don't have to code from scratch right?
The Rich Text Control provides the ability to _display and edit_ formatted
text. It's primary goal in life is _not_ to support every subtle nuance of
the rich text file format. You don't need the rich text file format -- you
don't need _any_ format -- to _display_ formatted text.
If you reread my previous note, you'll see that I was asking why the original
poster wanted to write rich text format files. If his users don't have Word,
or any other RTF-supporting word processor, why would he want to write such
files? It seems far more appropriate for his application to write data in his
own format and then allow users to view it with his application if he can't
guarantee that his users will have an appropriate viewer for rich text format.
Maybe he has a reason for that, so I asked if he could explain it. He
hasn't, to date, but I _did_ receive your long note about Write files.
> Word should not
> be the only app that can create/view RTF files.
It isn't. WordPad, AmiPro, and WordPerfect for Windows are three other
commercial programs (just off the top of my head!) that support rich text
format _files_. Supporting the file format and supporting viewing and editing
the data the file format contains represent two completely different problems.
> In fact (another
> complaint/suggestion here) Word 95 won't even create Write (.wri) docs
> anymore (an RTF of sorts) and
This is just plain wrong: it sounds like you just forgot to install the
converter. It's on the CD, and it works, if you install it.
> Write format is the ONLY non plain (rich)
> text doc format that can be viewed by all win32 systems using default OS
Write's format is decidedly _not_ a plain text format. Write files are
binary, and are a lot closer in structure to a native binary WinWord document
(at least as of WinWord 2.0--maybe things have changed to be far more OLE
compound-document centric) than they are to the RTF file format, which _is_ a
plain text format.
> Would be nice if the RTF common
> control read, displayed, printed and previewed .wri files and well as .rtf
> files well.
It doesn't: the control addresses two and only two data format, and those are
undecorated text and RTF. I've heard of no plans to have the control embrace
other data formats, aside from enhancing its support for RTF.
> I can no longer create them
Yes, you can:
1) get your MS Office Professional CD Stick it in your CD drive.
2) run the SETUP.EXE from the root directory of the CD. Since it sounds like
you already have Office 95 installed, you'll get the maintenance program.
3) Click the "Add/Remove..." pushbutton
4) Hilight the "Converters, Filters, and Data Access" item in the "Options"
list box.
5) Click the "Change Option" button
6) Highlight "Converters" in the newly repopulated "Options" listbox
7) Click the "Change Option" button
8) Highlight the "Write for Windows Converter" item in the "Options" box.
9) back out of the options dialogs by pressing "OK" repeatedly.
10) Let Setup proceed. you'll find that it will install the Write converter,
and you'll have "Windows Write 3.0" as a "Type" choice in your "Save As"
dialog in Word 95.
Anyway, this is the MFC list: I'm not sure I understand what WRI files have to
do with MFC or with my attempt at answering this other fellow (that is, not
you) who wanted to process RTF files without having the software to do so.
That is, I don't understand why you're using this forum to advertise your need
for this format, nor do I understand why you're so upset about Microsoft not
providing support for a file format that, it turns out, you just didn't
install.
> These features would make MFC all that more valuable for
> creating rich text based apps.
It's very common to confuse the features of Windows common controls with the
features of MFC. Programmers should be able to readily identify which part of
their environment is responsible for what features. To me, it seems like a
basic measure of that they be able to do this for their architecture. The
rich text control is implemented by Windows. The rich text control exists on
a Windows 95 or Windows NT 3.51 system even if MFC was never installed on that
machine. Adding support for foreign file formats to the operating system
doesn't seem like a very high priority at all for the operating system. It
certainly isn't a priority for MFC--we're more interested in supporting things
that the operating system supports.
Write is an application. There's no reason to bake every feature of an entire
application into the whole operating system. If you need to take the text in
a rich text edit control (which is a part of the operating system) and write
it out to a .WRI file, you can do so by writing code for yourself. The .WRI
file format is documented in the SDK (or, at least, it was there back in the
Win16 days when I needed it), so you have everything you need to get started.
> Mike, Could you pass this on to whomever appropriate at MSFT? Calling the
> WISH line (which I did) seems unlikely to carry the weight your suggestion
> might.
I'm not sure who is responsible for the developent of the rich text control,
so I'm afraid I'm unable to reflect your note to that group. It's laughable to
think, though, that that group would decide to support just because I
suggested it. I wouldn't suggest it anyway: I see that the folks who wrote the
rich edit control have embraced a particular set of features as their design
goal. They have a job to do, and it seems they're doing it very well.
It's a big shock to lots of people I talk to, and it'll probably be a big
shock to you, but: the functionality built into any piece of code must
necessarily be finite. That's mainly because resources are finite: there's
only so many testers and documentation folks and developers. And time is
fininte, too: there's eventually a ship date. The team that's developing the
rich edit control is probably focusing on a certain, much more limited (yet
much more attainable) set of goals than you're demanding they emrace.
As it stands, the rich edit control provides an outstanding amount of
functionality in a package that's trivial to reuse. There are issues to be
worked out, but the control as it stands provides what 99% of developers need,
which, as you said yourself, is displaying formatted text and allowing the
user to edit and reformat it. The 1% that needs something else will go off and
write their own code to get the rest of the way. In the form of this control,
they've been given a very long ladder that gets them most of the way.
No piece of software can be all things to everyone.
.B ekiM
http://www.nwlink.com/~mikeblas
Dave Kolb -- sasdxk@unx.sas.com
Tuesday, July 30, 1996
----------
> From: Mike Blaszczak
> To: mfc-l@netcom.com
> Subject: RE: Printing RTF contents
> Date: Friday, July 26, 1996 12:32 PM
...
> As it stands, the rich edit control provides an outstanding amount of
> functionality in a package that's trivial to reuse. There are issues to
be
> worked out, but the control as it stands provides what 99% of developers
need,
> which, as you said yourself, is displaying formatted text and allowing
the
> user to edit and reformat it. The 1% that needs something else will go
off and
> write their own code to get the rest of the way. In the form of this
control,
> they've been given a very long ladder that gets them most of the way.
>
> No piece of software can be all things to everyone.
>
> .B ekiM
> http://www.nwlink.com/~mikeblas
OK, I guess I deserved that speech since I got off topic so much. Thanks
for the info about .wri files and Word though.
Still it would be pretty nice if the RTF common control and CRichEditView
together supported MFC's Print Preview properly. Enjoyed your motoring
escapades especially the "clueless" description and keep putting those
samples out there.
Thanks,
--
Dave Kolb
SAS Institute
919-677-8000 x6827
| Вернуться в корень Архива
|