Question on dot matrix printing

Several of our clients use dot matrix printers and we're running across a curious problem.

Our customers use dot matrix printers for "speed mailers" usually 10in wide by 5.5in high cards that are sent to several thousand people at a time.

When printing from Word using this custom paper size (10inx5.5in), the dot matrix printer does exactly what you expect -- no matter what the paper size is in the dot matrix printer.

However, when printing from WPTools, the orientation automatically changes to so that the document is now 10in high and 5.5in wide.

Has anybody run across this issue with dot matrix printers in the past? The behavior is the same when printing to a laser printer as to a dot matrix printer. I think something is "automatically" telling the page to switch position based on some notion of a "default" paper size. Just a guess though....

Hi,

It could be because the printer uses different X and Y resolutions.

A possible solution would be to print on a metafile and export this to the printer. But I cannot test this here.

Julian

Using a metafile appears to work (just spending time on getting it to format correctly on the printer's canvas). Why does WPTools natively not print to metafile? I'm just curious why the "automatic" re-adjustment is happening for that paper size. It happens on both dot matrix and laser printers that I have attached to my machine.

Still having trouble getting the metafile to print properly on the page -- as the alignment of the metafile has a mind of its own when printing. I will go into this later. What I would like to do first is clearly describe the problem:

I am working on a document that is by default marked as "Portrait" (even though the page width is larger than the height -- that's ok). The page is 10in wide by 5.5in tall. The text on the page is from left-to-right (English) across the page.

When printing from WPTools to CutePDF, I print out the document and it appears as it does in the editor - 10in wide by 5.5in high. There is no need to rotate the resulting PDF because the text is reading left-to-right. When printing the PDF to the printer from Adobe Acrobat Reader, the document rotates counterclockwise 90 degrees and is printed on the page with the text reading from bottom-to-top.

When printing from WPTools to any printer with 8.5in by 11in paper, the text and page is automatically rotated -- clockwise by 90 degrees. It is as if the page is being printed in "landscape" on the page. The text here reads from top-to-bottom on the page.

When loading the same RTF document into MS WORD, printing the document produces "WYSIWYG" -- the text reads from left-to-right across the page. MS WORD knows enough to print the text across the page instead of automatically guessing that you would like the document in "landscape".

Why then does MS WORD and OPEN OFFICE print out "WYSIWYG" and WPTools does not?

When testing using your suggestion of metafiles, I ran across a similar problem. I am not able to have the text of the metafile appear WYSIWYG across the page, instead it rotates counterclockwise 90 degrees -- even though the printer canvas is set to the correct size of 10in wide by 5.5 in high. The result is that half of the letter appears on the page, the other half is cut off because the page is only 5.5in high.

If you need me to run any further tests, I can do so. Or, if you'd like, I can post the PDF results of the tests. Again, this is something that both MS WORD and OPEN OFFICE 2.0 can do "WYSIWYG".

I'm starting to investigate this issue myself and found the area where the issue is happening. WPCtrMemo.UpdatePrinterProperties (line
1250😎

landscape := pw > ph;

Just because the page width is greater than the page height does not mean that I want the page to print in landscape on the printer.

I will see if I can find a work around and submit the code here.

Hi,

You can use

landscape = Header.Landscape

that will work unless you have sections which rotate the page.

Julian

Thanks Julian! Would this fix the issue if we were looking at sections:

Add local variable:

props: TWPRTFSectionProps;

Then, get the section's properties from the RTF Data Collection using this virtual page's section id:

props := RTFData.GetSectionProps(RTFPage.SectionID);
      landscape := props.Landscape;

Would this be a more robust solution?

Hi,

This looks like an execllect solution - I did not think of it.

Julian