at first I would like to say the printing of the rtf content (> 1 page) with TD6.0 SP3 EMP5363 seems to work.
But there is a difference between preview and print.
I attached a sample that shows the difference.
1. Different Pagebreak
You see: In the preview the pagebreak is after "LED Seitenmarkierungsleuchten"
and after printing the pagebreak is some lines later.
2. Last RTF line in preview not shown
You see: In the preview the last rtf line is "7777777777777777777777" and the line "888888888888888888888" is missed
and after printing it is ok.
3. Different Page Count
The preview has 3 pages and the print 2.
(result of the different pagebreak)
4. Bad rendering with the internal pdf creator
With an external pdf creator (cib printer, adobe, ...) the rtf content in the pdf file is "TEXT"
but with the internal pdf creator the rtf content is a "PICTURE".
Now my customers have the problem that they always have to print the report in order to see where the pagebreak is.
Please Unify, fix these issues but be carefull and do not shot up the current functionality.
(We waited for a long time for the rtf function to work)
I must correct me to Position 2. "Last RTF line in preview not shown"
In some cases is the last rtf line also on the print not shown.
It is on depency from the length (lines) of the rtf.
That way is a lot better than one file's last line being "888888888888888888888888", another "5555555555555555555555" etc. Let me ask that you do that or similar too for any more? Thanks much!***** LAST LINE IN THE RTF FILE *****
S U M M A R Y
PREVIEW: defect TD-16140
tests 0 & 3 same defect issue, missing last line from RTF file. (NOTE: This is the only regression I saw. These are OK with v6 SP3, but with EMP5365 miss that last line.)
PRINT: defect TD-16141
test 0 extra blank page;
tests 0, 1 & 3 the same for no “Page Footer” line end of page 1;
tests 1 & 4 missing last line from long RTF and 2nd short RTF completely
(I did not get a crash with test 3, as you reported)
PDF: defect TD-16142
test 2 “RTF START” text line should be in line with RTF text, but RTF text is offset down nearly a line
thank you for the quick reply.
But it seems, that you see other defects as I.
Is there no different pagebreak on page 1 between preview and print on the sample in this thread ?
In my case there are some lines (rtf lines) more on print.
And does the "RTF test 2" sample not hang with only one rtf line ?
(there should be also no "ENTER" after the first rtf line!)
I tested on Win 7 Ultimate 32 Bit with an monitor resolution 1920 x 1200.
The standard papersize of my printer is A4 (210 x 297 mm).
can you tell me your settings?
In the future, maybe best to try to be *exact* in what you see and how to reproduce. I can only go by what is exactly written and how the test case works or not for me.
Sorry, but this is what I mean about being exact. What "ENTER"? What RTF line? if you mean the offset between text "RTF START" and the RTF text display in PDF test 2, that is noted as an 'offset' in the RTF text. That is, is is below the bkgnd. text; there's no CRLF ("ENTER") per se before the RTF text; the RTF text is just displayed lower than the bkgnd. text. That is how it is reported.there should be also no "ENTER" after the first rtf line!
with "ENTER" I mean CRLF and with RTF line I mean one text line in the rtf content.
But this thread contains also pictures and the first picture shows the pagebreak when you press the "Preview" button in the sample and
the second picture shows the pagebreak when you press the "Print" button in the sample.
On Preview the pagebreak is after "LED Seitenmarkierungsleuchten" and on print the pagebreak is after "Zusatzinstallation".
This is the difference what I mean.
And Jeff, it was also a lot of work for me to write this testcases and this is normaly not my task.
I only hope that the rtf functionality can finally be fixed.
now I wrote a new test app for testing the rtf functionality.
This app creates dynamicly rtf content for the report in detail block 1 and detail block 2.
With detail block 1 and 2 I mean:
Detail Block 1 is sended to the report on the first SAM_ReportFetchNext and
Detail Block 2 is sendet to the report on the second SAM_ReportFetchNext.
You can set the number of lines for the rtf content in the app.
Every line is numerated, so it's easy to see wich lines are missed.
This testapp shows also all other issues (different pagebreak between preview and print, overlapping from text)
Maybe Jeff, you can give this testapp to the development and they can test the rtf functionality.
It is necessary to play with different numbers of lines for the rtf content to be sure it works.
Also different fonts and fontsizes should be tested.
The app stores the latest settings in an ini file in the current working directory.
While processing Preview, Print or Creating PDF do not open detail1.rtf or detail2.rtf.
Even though rich text greatly enhanced the flexibility of the report, there are a couple of LIMITS the user should be aware of:
1. "fragmentation" of a big document
When a big document spans to several pages, the "fragmentation" could lead to overlap or extra space at the end of the document.
2. irregular document
When a big document includes huge images, tables, or big fonts could also lead to overlap or extra space at the end of the document.
3. difference between preview and print
[from his comment in another defect, TD-15923, he wrote this]
The difference between printing and preview, is a limit in MS rich edit control - it’s not able to linearly scale the rich text content. In a device with lower DPI ( dots per pixel ), like displays ( normally 96 ), the control needs more space than it does on a device with higher DPI , like printer ( normally 600 ).
To better understand the problem, it’s probably easier to do a simple test with MS WordPad bundled with Windows.
1. Open the attached RTF document with MS Wordpad
2. Go to “Page Setup”, set the margin as left = 1.25, right = 1.25, top = 0.25, bottom = 0.25
3. Go to preview , see the following screenshot , notice that in the bottom of first page, the content goes out of the page , and there is no margin.
4. Now print the report , go to the bottom of the first page, and you will see
You can see the text is correctly “contained” and doesn’t cross the margin area. It’s very clear that in MS WordPad, preview needs MORE space than print.
Now goes back to RB, when RB precisely keeps the objects ( like text field, box, picture ) precisely in the same position between preview and print, it has trouble doing layout for the rich text. The same rich text content needs less space in print, it’s inevitable to see the extra space. The only editor that won’t see the problem is MS Office, but it’s a premium editor, it always prints in the same area , [there is] no dynamic data, [MS Office] doesn’t get mixed up up with other objects ( like picture, text, graphic objects ).
Who is online
Users browsing this forum: [Ccbot] and 0 guests