Beiträge von nnegulescu

    One of our customers is having a difficult time when printing documents from our application which use sections. The difficulties include when printing to file and printing to a printer.

    Each record in a database is being printed on a page by itself. A new section is created for each record by using the AppendAsSection(...) method on the editor.

    The issue is that the first and last pages print fine -- using portrait mode. The middle documents print in landscape mode even though the section was appended in portrait mode.

    We have not been able to reproduce the customer's issue when printing directly from WPTools.

    We have been able to reproduce the issue when printing from Word 2002. I understand that there might not be a one-to-one correspondence between RTF variables in WPTools and MS Word.

    Below you can see the document source we are having issues with. We are using WPTools 5.20.8 although the document itself might predate 5.20.8. Is there anything that you can think of that might be causing this issue? Has anyone else reported sections printing using the wrong page orientation? Thanks in advance!

    I've been having some difficulties getting an editor to print it's contents to a different printer tray (bin).

    We are currently using 5.20.8, D2005. I have this code:

    Code
    Editor := TWPCustomRichText.CreateDynamic;
    Editor.CheckHasBody();
    
    
    ... add some text to editor here...
    
    
    Editor.PrintParameter.AllPagePaperSource := 3; //Tray 3
    Editor.Print();

    Every time, the page is printing to the default printer tray in our case -- Tray 2 (not Tray 3). It doesn't matter what Tray I'm selecting and assigning to the "AllPagePaperSource", the page is coming out on Tray 2.

    Am I missing some code? I looked at the PrinterSetup demo it wasn't immediately obvious that we were missing any steps. Do we need to call another method to synchronize the PrintParameters with the TPrinter object?

    If I make text in one portion of a paragraph in one font size and then the other portion of the paragraph in another font size, It does not show the font size in the tool bar. Does anybody know how to fix this issue?

    When adding center justified bullets to a document (don't ask me why someone would do this...), the bullets appear to work just fine before any text is added to that paragraph. As soon as the user types one letter, the bullet point jumps over to become left justified while the text remains in the center of the document. Furthermore, when adding a new paragraph below the just-entered bullet, the bullet stays in the center while the text appears close to the right margins of the document.

    I have created a screencast of this which is available here:

    Our customers have been having problems with older versions of their WPTools letters. I have created a web cast of the issue that they have been having.


    When the video first starts, I open a document which is titled "Evil Line". This is an RTF document that was created using WPTools 5. It contains both a header and a footer and the cursor is displaying as a very small cursor.

    As you can see in the video, when I open the document, you can see the cursor appears to be VERY SMALL. I cannot type anything there.

    When I click the DOWN arrow button, I move to the second line where the cursor appears to be only a fraction of the actual text size. Now the text size does not appear in the menu bar!

    Why is the cursor appearing in a very small size and why when I type "testing" is no font size associated with the text? When I highlight the text, you can see the font-size is 11. When the cursor object is just inserted into the word however, no font size is selected.

    We're running across some issues with appending a large number of documents together. We are getting an Out of Memory error from windows -- which varies depending on the machine. What we are noticing is that there is no disk caching happening before the error is thrown. This might be the normal behavior of TMemoryStream -- not sure, haven't looked into it that far yet.

    We're looking for any advice you have for managing large documents -- over 500 pages. What sorts of issues do you run into at that size of document?

    We did find https://www.wpcubed.com/forum/viewtopic.php?t=648. We're getting the same Out of Memory error message as in https://www.wpcubed.com/forum/viewtopic.php?t=2800.

    Our solution is using a TWPPreview component which is updated by a TWPCustomRichText (we used this approach because of the component hierarchy). After every "append as section" call on the customRTF object, the TWPPreview panel is updated with an

    Code
    preview.AsString := customRTF.AsString;

    We have run some tests where the merge program runs out of memory at 118,000K and sometimes at 159,000K (on a 2GB memory machine). Our customers have the potential of printing 1000+ page documents. Do you have any other components that would make this job easier? Manage memory better?

    I see the problem as one where the model of concatenating all of the merged documents together does not scale well -- given memory limitations. I know some other reporting tools only merge one "record" at a time and just let the document spool to the printer and let the spooler do the work. Any insight here?

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

    Add local variable:

    Code
    props: TWPRTFSectionProps;

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

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

    Would this be a more robust solution?

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

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

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

    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.

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

    To insert the total number of pages, I call the following code:

    Code
    Editor.InputTextField(wpoNumPages);
      Editor.ReformatAll();


    When a user is in the Editor visual component they can italicize and boldface the 'wpoNumPages' object, but it cannot be underlined. I'm running 5.20.8.

    Anybody know about this issue and have a workaround?