Print to PDF from AppleWorks 5.1? - Yes, Virginia
Hugh Hood
I'm probably easily amused, but thanks to being off from work and having my
wife out of town for a few days, I've finally perfected a method to generate
.pdf files from AppleWorks Word Processing, Database, and Spreadsheet files,
and to do it from _within_ AppleWorks 5.1.
This is _not_ an epic effort, like the coding of Eric, Ewen, Antoine, Ivan
and the many other Apple II 'pros' has been, and admittedly it uses bits and
pieces of existing works, but I must say, the end results are slicker than
Shinola.
So many Apple II-based documents over the years were stored in AppleWorks
Word Processor format, and include, in addition to formatting codes (Bold /
Italic / Underline / Center / Justification), different font sizes and font
styles, page headers, page footers, page numbers, etc...
Even data base reports and spreadsheets, while not as 'format-rich', contain
information that would benefit from being inside a modern .pdf file.
Since AppleWorks 5.1 also loads standard text files and Merlin Source files,
they are also candidates for easy conversion.
Moreover, there are still a few of us (OK, very few, but I'm one) who still
use AppleWorks daily in a business setting to generate documents, including
Purchase Orders, Invoices, Quotations, Financial Schedules and the like, and
who have gotten tired, in today's modern climate, of having manually to scan
in AppleWorks documents to comply with the new-age request of 'Just email it
to me.'
AppleWorks 5.1, out-of-the-box, contains an HP PCL printer driver that
allows many formatting options, including a myriad of different fonts
(including a proportionally-spaced Times Roman). Advanced users, by
embedding certain Escape codes in the documents, are able to select PCL
printer macros, which allow complex Logos and forms to be stored in the
printer and to then be used on demand from within documents. These are
especially great for having things like a built-in letterhead or a built-in
invoice form. Neat, neat, stuff, or at least it seems so to me. But, then
again, I'm easily amused. <grin>
Anyway, I'll document all this next year, and if Sean thinks it's good
enough, maybe he will put it up under 'Howto' on his A2Central.com website
as a companion piece to my Apple II - Unix serial terminal article. Even if
it doesn't make it to the prime time, I'll put it up someplace.
It's not that involved, but it does require you have access to a 'modern'
computer to which you will cable your Apple II serially. That 'modern'
computer will become your PDF Printer.
Some key points.
1. The Apple II part of this works automatically from within AppleWorks. You
load your file to the AppleWorks Desktop, enter 'TimeOut Print2PDF', and
within seconds, your file shows up as a .pdf on your 'modern' computer.
2. The 'modern' computer will need to have Unix underpinnings. I'm using Mac
OS X, but Linux or other variants should work as well if not better.
3. The pdf engine on your 'modern' computer will use the open-source
GhostPCL from the GhostScript folks. (But we will _NOT_ use the substituted
monospaced Courier and Letter Gothic fonts supplied, as they are much too
thin and just don't look good, either when printed or when viewed on the
screen. - The other 70+ fonts are fine, though.)
4. On the Apple II, the TimeOut Application (a compiled series of fairly
involved macros, BTW - source code provided) will automatically Log on to
the Unix machine, change the Unix directory to the desired default location
for the file (I like the Desktop on the Mac), invoke the pcl to pdf engine,
print/send the document, close the pcl to pdf engine, and Log off the Unix
machine.
If you'd like to see a sample of the output this produces, I will direct you
to the usual ftp 'suspect' for downloading all things Apple II. I can't
recall its name at the moment. Someone else will know. <grin>
In the 'documentation' folder, go to the 'applications' subfolder, and then
to the 'appleworks' subsubfolder.
The file to examine is:
AW5UltraMacrosReferenceV1.pdf
This is Joe Walter's beautifully-done UltraMacros Reference Manual. It
numbers 150+ pages, includes both mono spaced and proportional fonts,
italics, bold face, page headers, etc... Joe even included a Table of
Contents and a couple of indices.
That pdf was made with this technique straight from within AppleWorks 5.1,
although I added the author name to the pdfmarks after-the-fact. Otherwise,
it's untouched.
For the record, Joe made the manual freeware and it has been available for a
number of years as a series of macros and data files that allow you to
'build your own'. This is a very cumbersome process that I'll bet dissuaded
more than a few people. Now in .pdf form, it is far more accessible.
{Since there were a small handful of UltraMacros .dot commands written by
various authors after Joe wrote his reference and were therefore not
included in the book, I term this pdf Volume 1. We'll see about a Volume 2
addendum someday.}
Finally, this same TimeOut application will be improved to allow FAXing from
within AppleWorks 5.1.
I've already got it coded, but not tested, since the doggone Dash2 Internal
Modem on my Mac has been flaky for years and is just not cooperating. It
dials the number, but hangs up on a 'protocol error'. I plan to replace it
with an external FAX modem and go at it again. That's for those requests
from customers to 'Just FAX it to me'. Hey, the customer's always right,
right? OK.
In the meantime, if you've just _have_ to have one of your AppleWorks
documents converted to .pdf, let me know. Maybe I can do it for you.
Hugh Hood
Michael J. Mahon
Hugh, which "usual suspect" FTP site? There are a bunch, and
I just checked Asimov and that wasn't it... ;-)
-michael
NadaNet 3.1 for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
Hugh Hood
Your first suspect was indeed correct.
They seem to have strange, strange, alphabetizing 'rules' there. Some of
their mirrors are more conventional, though.
Here's the directory:
<ftp://ftp.apple.asimov.net/pub/apple_II/documentation/applications/applewor
ks/>
It's the first file.
Hugh
Sean Fahey
> Anyway, I'll document all this next year, and if Sean thinks it's good
> enough, maybe he will put it up under 'Howto' on his A2Central.com website
> as a companion piece to my Apple II - Unix serial terminal article. Even if
> it doesn't make it to the prime time, I'll put it up someplace.
Hugh, I'll be happy to post it.
Toinet
I have several AW files I will be glad to print out as PDFs with your
solution.
Thank you,
antoine
Michael J. Mahon
> Michael,
>
> Your first suspect was indeed correct.
>
> They seem to have strange, strange, alphabetizing 'rules' there. Some of
> their mirrors are more conventional, though.
>
> Here's the directory:
>
> <ftp://ftp.apple.asimov.net/pub/apple_II/documentation/applications/applewor
> ks/>
>
> It's the first file.
>
> Hugh
Thanks--that's what I get for not viewing the site in
File Explorer mode! All the directories were interleaved
with the contents, and I only checked the top and the bottom. ;-)
Michael J. Mahon
The .pdf is beautiful--this will make a very nice utility!
One thing I noticed that is funny...the Times Roman font seems to
be mixed point size. The lower-case letters "hflk" and "tuvwxyz"
(and probably more I didn't check) are larger than the rest, and
(at least) the digit 6 is smaller than other digits.
Is this font embedded, or is this a rendering issue for Adobe Reader
on my machine? Perhaps the point size is some fractional value??
Hugh Hood
Thanks for the compliment.
The pcl - pdf engine embeds font subsets so that the reader need not have
the original fonts installed.
In the case of the proportional Times-Roman font that the AppleWorks PCL
driver uses, the default substitute font is URW's "NimbusRomanNo4-Lig",
although when the engine is actually built, other fonts (including
originals) can be substituted.
The engine uses the substitute fonts 'just in case' someone were to create a
pdf without having 'embedding' privileges for the fonts they are using. As
you know, most of us have bucket loads of fonts these days, and just about
everything I own allows embedding into a .pdf. YMMV.
In fact, the default fonts selected by the engine for the Monospaced fonts
the AppleWorks PCL Driver uses (generally Courier and Letter Gothic) were
wholly unsatisfactory, so when I built the engine, I used the real McCoys.
Most printing (but not all) printing from AppleWorks is done with monospaced
fonts, so I felt those were the most important.
Anyway, I didn't really notice the "hflk" issue you mentioned with my (2)
readers, Acrobat 8 (Mac) and Apple Preview. Could I trouble you to get back
to me with a specific page number so that I can take a better look?
One more thing -- do you notice the same thing when the particular page is
printed?
Thanks.
Hugh Hood
in article F7qdnZPvZ4xZBZLQ...@giganews.com, Michael J. Mahon
at mjm...@aol.com wrote on 12/20/10 11:56 AM:
Hugh Hood
Thanks.
I appreciate your offer and will do you a good job.
Hugh Hood
in article
0619341f-26b9-4f0d...@k22g2000yqh.googlegroups.com, Sean
Fahey at a2...@hotmail.com wrote on 12/20/10 8:05 AM:
Michael J. Mahon
> Michael,
>
> Thanks for the compliment.
>
> The pcl - pdf engine embeds font subsets so that the reader need not have
> the original fonts installed.
>
> In the case of the proportional Times-Roman font that the AppleWorks PCL
> driver uses, the default substitute font is URW's "NimbusRomanNo4-Lig",
> although when the engine is actually built, other fonts (including
> originals) can be substituted.
>
> The engine uses the substitute fonts 'just in case' someone were to create a
> pdf without having 'embedding' privileges for the fonts they are using. As
> you know, most of us have bucket loads of fonts these days, and just about
> everything I own allows embedding into a .pdf. YMMV.
>
> In fact, the default fonts selected by the engine for the Monospaced fonts
> the AppleWorks PCL Driver uses (generally Courier and Letter Gothic) were
> wholly unsatisfactory, so when I built the engine, I used the real McCoys.
>
> Most printing (but not all) printing from AppleWorks is done with monospaced
> fonts, so I felt those were the most important.
>
> Anyway, I didn't really notice the "hflk" issue you mentioned with my (2)
> readers, Acrobat 8 (Mac) and Apple Preview. Could I trouble you to get back
> to me with a specific page number so that I can take a better look?
>
> One more thing -- do you notice the same thing when the particular page is
> printed?
No, the printed page is perfect.
I see what produces the problem--Adobe Reader page scaling!
As I view page 1 (the first with Times Roman) on my machine
and change the zoom (fit page width, then vary the window size)
from 79% to 78.9%, the letters scale differently.
So 79% zoom and larger all look perfect, and 73.7% to 78.9% have
some letters larger than others!
It's a strange effect, which I realize I have seen before, but
never played with it to discover how it worked.
There must be some weird rule in Reader's font scaling, at least
on Windows. BTW, as I change the zome smoothly, the line spacing
jumps up and down--no doubt a result of rounding to the nearest
raster line. This font rendering issue is no doubt related.
sicklittlemonkey
> There must be some weird rule in Reader's font scaling, at least
> on Windows. BTW, as I change the zome smoothly, the line spacing
> jumps up and down--no doubt a result of rounding to the nearest
> raster line. This font rendering issue is no doubt related.
It may be caused by Windows. Here's an interesting pic:
http://stackoverflow.com/questions/190344/wpf-blurry-fonts-problem-solutions
(Look for the "cascade" pic in the top answer.)
When we have truly hi-res monitors, ClearType and WPF will solve the kinds of problems you see in Reader. (Unless it truly is an Adobe thing!)
Cheers,
Nick.
Michael J. Mahon
That would be great--but until the resolution of the monitor
exceeds the resolution of my eyes, there will always be some
quantization effects--with antialiasing (blurring) required to
paper over them.
The curious thing about this effect is its discrete nature and
its selective effects--the inequalities only appear at specific
sizes and to specific ranges of letters (not shapes or sizes of
letters).
The difference is not subtle--it's at least a 10% variation in
point size.
I'm running Vista on this machine, and I thought that font
antialiasing was the default setting. Maybe an application
can override the default.
I've only noticed this effect in Reader, but it's also the
easiest app to vary font scaling continuously.