Bug Hunting Session
Bug 37488 - PRINTING table borders in Writer not printed if there are also images in the document, DRAW object printed crippled
Summary: PRINTING table borders in Writer not printed if there are also images in the ...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.0 RC1
Hardware: Other Windows (All)
: highest critical
Assignee: Don't use this account, use tml@iki.fi
URL:
Whiteboard: target:3.4.2
Keywords: regression
: 37670 37867 37975 37992 38041 38228 38609 38839 38865 38897 (view as bug list)
Depends on:
Blocks: mab3.4 38993
  Show dependency treegraph
 
Reported: 2011-05-23 01:26 UTC by Rainer Bielefeld Retired
Modified: 2011-11-09 23:10 UTC (History)
20 users (show)

See Also:
Crash report or crash signature:


Attachments
Pls. see original report (310.93 KB, application/vnd.oasis.opendocument.text)
2011-05-23 01:26 UTC, Rainer Bielefeld Retired
Details
Print results (131.03 KB, application/x-zip-compressed)
2011-05-23 02:01 UTC, Rainer Bielefeld Retired
Details
Repaces defective original sample document (309.35 KB, application/vnd.oasis.opendocument.text)
2011-05-23 02:05 UTC, Rainer Bielefeld Retired
Details
Output on Linux with LO-3.4.0-rc1 (277.82 KB, application/postscript)
2011-05-23 10:43 UTC, Petr Mladek
Details
Simple odt file with the bug (17.49 KB, application/vnd.oasis.opendocument.text)
2011-07-06 00:43 UTC, Nicolas R
Details
Lean test document (345.00 KB, application/x-zip-compressed)
2011-07-06 00:57 UTC, Rainer Bielefeld Retired
Details
Sample files .odt, .pdf, .eps (18.41 KB, application/zip)
2011-07-06 06:47 UTC, manj_k
Details
Minimal sample document (561.39 KB, application/vnd.oasis.opendocument.text)
2011-07-11 08:48 UTC, Don't use this account, use tml@iki.fi
Details
Another minimal test case (37.63 KB, application/vnd.oasis.opendocument.text)
2011-07-12 04:39 UTC, Don't use this account, use tml@iki.fi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2011-05-23 01:26:39 UTC
Created attachment 47026 [details]
Pls. see original report

With attached sample document and "LibreOffice 3.4.0RC1  – WIN7  Home Premium  (64bit) German UI [OOO340m1 (Build:11)]" print results are completely unusable.

I print pages 5-7 from "test101.odt" and see

With HP OJ6110 (default WIN7 drivers):
Table: borders missing
Envelope object: crippled
Radio buttons on last page under "Vertrags-Details": Printed at the end of the document and much too big
Footer LibO label: missing

With Okipage 14ex (default WIN7 drivers):
Table: borders missing
Envelope object: crippled
Radio buttons on last page under "Vertrags-Details": missing
Footer LibO label: missing

PDF export is ok

OOo3.1.1 prints the same document correctly

That was ok with LibO 3.3
Comment 1 Rainer Bielefeld Retired 2011-05-23 02:01:31 UTC
Created attachment 47029 [details]
Print results

You can see my print results in Postscript files created with "Dell open print driver" (I think it's in the WIN drivers repository ore somewhere available for free):

myprint5.ps:
Both envelope pictures vrom OLE object messed up  (envelope too small, "@" not visible correctly)
Borders in table are missing
LibO symbol in footer is missing

myprint6.ps:
Borders in table are missing
LibO symbol in footer is missing
No idea what the blue bar has been in the original document

myprint7.ps:
Radio Buttons behind "Mehrwertsteuer" missing
LibO symbol in footer is missing

The results also are visible printing a PDF with FreePDF (what IMHO uses an Apple PS printer.
Comment 2 Rainer Bielefeld Retired 2011-05-23 02:05:06 UTC
Created attachment 47030 [details]
Repaces defective original sample document

In sample document Envelope OLE DRAWing object was missing
Comment 3 Petr Mladek 2011-05-23 10:43:43 UTC
Created attachment 47059 [details]
Output on Linux with LO-3.4.0-rc1

It looks much better on Linux with LO-3.4.0-rc1. It is with our network printer. I can't see the driver name anywhere.
Comment 4 Marek 2011-06-05 23:52:58 UTC
Table borders seem to be missing during the print-out if the document contains any graphic (like company logo). However they are fulli exported to the PDF file under LO however they dissapear again if you export the file to PDF using virtual print drive (like PDF Creator).
Comment 5 Marek 2011-06-06 00:10:19 UTC
(In reply to comment #4)
> Table borders seem to be missing during the print-out if the document contains
> any graphic (like company logo). However they are fulli exported to the PDF
> file under LO however they dissapear again if you export the file to PDF using
> virtual print drive (like PDF Creator).

Forgot to add that the bug is present in the newly released LO 3.4 (not only in the RC version)!
Comment 6 Rainer Bielefeld Retired 2011-06-06 04:08:49 UTC
I think bug is confirmed by comments 4,5.

May be many users like me can't use LibO  for the very basic job "printing a text document with Tables and DRAW objects", so I will nominate this one for 
"Bug 35673 - LibreOffice 3.4 most annoying bugs"

@Cédric:
Please feel free to reassign if it's not your area!
Comment 7 Oliver Brinzing 2011-06-06 10:01:47 UTC
.
Comment 8 Andras Timar 2011-06-07 00:22:59 UTC
*** Bug 37992 has been marked as a duplicate of this bug. ***
Comment 9 manj_k 2011-06-07 13:56:26 UTC
*** Bug 38041 has been marked as a duplicate of this bug. ***
Comment 10 manj_k 2011-06-08 14:51:51 UTC
*** Bug 37975 has been marked as a duplicate of this bug. ***
Comment 11 Edu 2011-06-10 05:59:47 UTC
I have the same problem. This version of Writer is not usable for now
Comment 12 Rainer Bielefeld Retired 2011-06-13 08:34:03 UTC
*** Bug 38228 has been marked as a duplicate of this bug. ***
Comment 13 HansPeter Roesli 2011-06-15 02:15:43 UTC
(In reply to comment #12)
> *** Bug 38228 has been marked as a duplicate of this bug. ***

This is fine with me. Note however:
The fact that LO 3.4.0 messes up printing and that in all former version I never got the spell checker working is a blocking issue for my multi-lingual environment.
Comment 14 manj_k 2011-06-23 13:27:37 UTC
*** Bug 38609 has been marked as a duplicate of this bug. ***
Comment 15 Nicolas R 2011-06-28 09:36:52 UTC
Could this issue be considered as a blocker for release 3.4.1 ?
I've read about an 3.4.1rc3 for another blocker.

IMHO (and also in my humble company ;) ) it's a blocker for 3.4 deployment. We have many documents with a logo and a tables with borders which will be unprintable.

Thanks !
Comment 16 Rainer Bielefeld Retired 2011-06-28 09:45:34 UTC
(In reply to comment #15)

> IMHO (and also in my humble company ;) ) it's a blocker for 3.4 deployment.

A poor workaround is to export to PDF (what works fine) and to print the PDF. I doubt that can be fixed before 3.4.2
Comment 17 Petr Mladek 2011-06-29 01:19:18 UTC
We already have 3.4.1-rc3, so it is too late to add any other fix. The blocker was the bug #38590. It was regression against 3.4.0, caused heavy data loss and affected almost all Linux users.

I am afraid that this bug can't be considered as a blocker because there is the workaround, ... Anyway, I have increased the priority.

Cedric, is there any chance to fix this for 3.4.2?
Comment 18 Nicolas R 2011-06-30 01:54:52 UTC
So we'll wait for 3.4.2 !
Comment 19 vitriol 2011-06-30 23:27:40 UTC
*** Bug 38839 has been marked as a duplicate of this bug. ***
Comment 20 vitriol 2011-06-30 23:28:27 UTC
*** Bug 38865 has been marked as a duplicate of this bug. ***
Comment 21 vitriol 2011-06-30 23:32:27 UTC
This bug makes LibO 3.4.0/3.4.1 completely unusable.
Comment 22 vitriol 2011-07-01 12:00:40 UTC
*** Bug 38897 has been marked as a duplicate of this bug. ***
Comment 23 tommy27 2011-07-02 02:09:16 UTC
I agree with VITRIOL... printing documents is a basic feature that cannot be so messy... it's urgent to fix this in 3.4.2....

I will stick to LibO 3.3.3 till this issue hasn't been fixed...
the pdf workaround is not acceptable in a productive environment
Comment 24 DESAUNAY 2011-07-02 02:38:16 UTC
Defining the PDF workaround as a solution is a lazy programmer's answer. Printing a doc is the basic of a Word Processor.
In parallel, the Foundation will work on far much more 'geeky' features.
This has nothing to do with quality.
Such behaviours are the root of free software's reputation vs commercial products.
Comment 25 Cor Nouws 2011-07-02 02:50:39 UTC
@desaunay, tommy27: no doubt this one will be picked up asap.
All involved people are aware this is needed for production environments.
Comment 26 tommy27 2011-07-02 23:08:04 UTC
(In reply to comment #25)
> @desaunay, tommy27: no doubt this one will be picked up asap.
> All involved people are aware this is needed for production environments.

I hope so. But how do you explain this:
"LibreOffice 3.4.1 fixes several bugs that affected the previous version, and can be safely deployed for production needs by most users."

this comes from your release announcement...
http://blog.documentfoundation.org/2011/07/01/libreoffice-3-4-1-provides-stable-new-features-for-every-user/

I think most users need a word processor that can print without any issue, so LibO 3.4.1 cannot be safely used by them.

please, understand what is the point of my critics... I'm not ranting against you... I know that the LibO 3.4.x development is still work in progress and is still affected by many bugs... I use the 3.3.x series and I'm very happy with it, and I know that sooner or later Lib 3.4.x will be stable.

the problem is about newcomers, people who download LibO for the first time...
if their first experience with LibO is affected  by such a serios bug like the present one, they will not probably give LibO a second chance...

my suggestion is to be more prudent with your release bullettins...
you cannot tell people that 3.4.1 is almost ready for production needs while it still have such important bugs...
Comment 27 Cor Nouws 2011-07-04 05:24:41 UTC
I tried - as far as provided - all attachments from the duplicate issues. Prints on Ubuntu, does not print on Windows
Comment 28 manj_k 2011-07-04 12:15:36 UTC
@Cor
It's worse: The borders (of tables and frames) appear mostly as pretty bold lines elsewhere in the printed document.
Comment 29 Cor Nouws 2011-07-04 14:00:57 UTC
hmm, appologies.
I printed 4 of the usable attachments from the issues, and none showed the strange line. But just tried the fifth, and indeed, that one (Copia de Plantilla_Defensoria-OpenOffice.ott) does have the problem.
This all on WinXP, BTW
So then might turn out that we have more than one issue at hand?
Comment 30 manj_k 2011-07-04 14:42:50 UTC
The strange lines appear in the attached 'Print results' (i.e.: 'myprint5.ps', 'myprint6.ps') by Rainer Bielefeld (see Comment #1), and--as far as I remember-- they appear also in all attachments of bugs, which I have marked as a duplicate of this bug 37488.
I believe it's a single issue... ;)
Comment 31 Rainer Bielefeld Retired 2011-07-04 21:12:53 UTC
The original report also was concerning crippled DRAWing printing in documents with table.
Comment 32 Cédric Bosdonnat 2011-07-05 06:17:09 UTC
Tor, a windows-only bug for you
Comment 33 Don't use this account, use tml@iki.fi 2011-07-06 00:20:29 UTC
Cédric's first guess that it would be the lcl_DrawDashedRect() method in sw/source/core/layout/paintfrm.cxx that needs debugging was wrong, I didn't see that method getting called at all when printing the "Copia de Plantilla..." test document from one of the duplicate bugs. (This is apparently the simplest document we have to reproduce the problem? Can somebody come up with an even simpler sample document that exhibits the bug, please?)

(Sigh, debugging this will cause paper waste;)
Comment 34 Nicolas R 2011-07-06 00:42:00 UTC
(In reply to comment #33)
> (Sigh, debugging this will cause paper waste;)
On windows, you can use a virtual pdf printer (like PDFCreator), the bug is still present with this kind of printer.

I'll add a simple odt file with the bug :

- print (even virtual pdf printer) : no border around the table
- export to pdf : it's ok
- delete the image : print or export, it's ok

(Win 7 Pro 64 bits, LibO 3.4.1 french with english ui)

I think if you solve the problem with this "not real life" document on virtual pdf printer ... you can successfully test with "real life" document and "paper waste" printer. ;-)
Comment 35 vitriol 2011-07-06 00:43:01 UTC
(In reply to comment #33)

> Can somebody come up with an even
> simpler sample document that exhibits the bug, please?

- Open Writer
- Insert a table
- Insert a image into a cell via Insert > Image > From file...
- Print

That's all.

> (Sigh, debugging this will cause paper waste;)

You can use a PDF virtual printer for testing.
Comment 36 Nicolas R 2011-07-06 00:43:48 UTC
Created attachment 48801 [details]
Simple odt file with the bug
Comment 37 Rainer Bielefeld Retired 2011-07-06 00:57:45 UTC
Created attachment 48802 [details]
Lean test document

Yes, Sir! :-)

My new test kit contains:
newsample3.odt: test document to reproduce all (?) problems except "Table lines 
                appear somewhere in the document 
newsample3.pdf: print result with FreePDF print (same results with DELL free 
                PostScript Printer)
newsample3results.odg: Print results with marked errors I saw

BTW, if you find out why the little OOo logo can't be deleted:
"Bug 34186 - Can not delete Picture"
Comment 38 Don't use this account, use tml@iki.fi 2011-07-06 04:54:10 UTC
Not even necessary to install a 3rd-party virtual PDF printer; the "Microsoft XPS Document Writer" can be used to demonstrate, too, it seeems. (I don't know if that is always present, or came with MS Office?)  Good.
Comment 39 vitriol 2011-07-06 05:03:55 UTC
(In reply to comment #38)

> (I don't know if that is always present, or came with MS Office?)

I think that it comes with .NET Framework.
Comment 40 manj_k 2011-07-06 06:46:05 UTC
Simple sample with "strange line":
- 'header_border_image.odt' (14 KB)
- 'header_border_image.pdf' (9 KB)
- 'header_border_image.eps' (7 KB)

1. Text document, Page style 'Defaut' with 'Header on', 
   'Bottom Border only', Width 0,50 pt, Color 'Light blue'
2. Insert > Image 'x.png'
3. Saved as 'header_border_image.odt'
4. Exported as 'header_border_image.pdf'
5. Created 'header_border_image.eps' with PDFCreator
6. Print...
or
7. Open 'header_border_image.eps' with GSview...
Comment 41 manj_k 2011-07-06 06:47:51 UTC
Created attachment 48819 [details]
Sample files .odt, .pdf, .eps
Comment 42 Don't use this account, use tml@iki.fi 2011-07-06 06:49:28 UTC
No need for any more reproduction instructions or sample files, thanks. Comment #35 has instructions for a minimal test case, and is enough. And printing to XPS and using the XPS viewer allows me to reproduce just fine without actually printint to paper, I won't bother with any 3rd-party print-to-pdf or print-to-postscript tools.
Comment 43 Don't use this account, use tml@iki.fi 2011-07-11 08:48:11 UTC
Created attachment 48978 [details]
Minimal sample document

Just an 1x1 table and an image. If the image is the last selected item, the bug shows up, if some part of the table is, it doesn't. Or something like that.
Comment 44 Don't use this account, use tml@iki.fi 2011-07-11 08:51:18 UTC
I have been debugging this for some days but not really come up with anything that would tell me what the problem actually is... I know that in the buggy case, GDIMetaFile::Play( OutputDevice* pOut, sal_uLong nPos ) in vcl/source/gdi is called with a metafile containing just 55 elements, in the non-bug case, 96 elements. But at what stage the table (and its borders, or the lines forming the borders, or whatever) get dropped, no idea.
Comment 45 Rainer Bielefeld Retired 2011-07-11 09:05:54 UTC
"Minimal sample document" seems to show only the table problem, but not the (table related?!) Drawing print problem from my "Lean test document".
Comment 46 Don't use this account, use tml@iki.fi 2011-07-11 09:11:11 UTC
That is intentional. One kind of bug per bug report.
Comment 47 Rainer Bielefeld Retired 2011-07-11 09:28:34 UTC
@Tor:
It's your decision, I am pretty sure that both effects at least have the same root, the crippling only appears with table in document.
Comment 48 Nicolas R 2011-07-11 13:08:49 UTC
(In reply to comment #43)
> Created an attachment (id=48978) [details]
> Minimal sample document
> 
> Just an 1x1 table and an image. If the image is the last selected item, the bug
> shows up, if some part of the table is, it doesn't. Or something like that.

In my test document ( comment 36 ), the problem "non printing" table border always occurs. 
- If you select "nothing" (cursor in first position): problem
- If you select the image : problem
- if the cursor is in the table with nothing selected : problem
- if you select the word "first" from the first cell : problem
- if you select the whole first cell : problem 
- if you select the whole table : problem

Only case the border are printed : you select the whole table and , in the print dialog , you choose to print "Selection" (default choice) and not "All pages".

Oh and perhaps a new bug ( I've still not searched bugzilla) :
- Something (e.g. the table ) is selected.
- You choose "Print"
- In the print dialog, default choice for "Range and Copies" is printing "Selection"
- You choose to print "All pages"
- Then choose again to print "Selection"
- Crash !
Comment 49 Don't use this account, use tml@iki.fi 2011-07-11 23:41:11 UTC
Please, for the sanity of developer(s) trying to debug this problem, let them (us) concentrate on just the simplest minimal test document from now on here in this bug report, OK? And no speculation whether some problem with a completely different outcome (a crash) is related, thanks.
Comment 50 Don't use this account, use tml@iki.fi 2011-07-12 00:17:34 UTC
FWIW, he is some debugging output showing what GDIMetafile "actions" are present in the non-buggy vs. buggy case when printing the sample document from comment #43.

OK:

WinSalPrinter::StartPage()
GDIMetaFile::Play (2): nPos=-1 count=96
  PUSH
  MAPMODE
SetMapMode(new)
  returning at 826
  MAPMODE
SetMapMode(new)
  setting maMapMode=rNewMapMode at 864
  origin=(-568,-568) scale=(1/1,1/1) at 889
  LINECOLOR
  FILLCOLOR
  MAPMODE
SetMapMode(new)
  returning early, identical mode
  PUSH
  LINECOLOR
  PUSH
  LINECOLOR
  RECT
  POP
  PUSH
  LINECOLOR
  RECT
  POP
  PUSH
  LINECOLOR
  RECT
  POP
  PUSH
  LINECOLOR
  RECT
  POP
  POP
  PUSH
  PUSH
  ISECTREGIONCLIPREGION
  POP
  POP
  PUSH
  CLIPREGION
  TEXTLANGUAGE
  LINECOLOR
  COMMENT
  LINECOLOR
  FILLCOLOR
  POLYLINE
  COMMENT
  TEXTLANGUAGE
  LINECOLOR
  COMMENT
  LINECOLOR
  FILLCOLOR
  POLYLINE
  COMMENT
  TEXTLANGUAGE
  LINECOLOR
  COMMENT
  LINECOLOR
  FILLCOLOR
  POLYLINE
  COMMENT
  TEXTLANGUAGE
  LINECOLOR
  COMMENT
  LINECOLOR
  FILLCOLOR
  POLYLINE
  COMMENT
  POP
  LAYOUTMODE
  LAYOUTMODE
  FONT
  TEXTALIGN
  TEXTFILLCOLOR
  FONT
  TEXTALIGN
  TEXTFILLCOLOR
  FONT
  TEXTALIGN
  TEXTFILLCOLOR
  PUSH
  PUSH
  ISECTREGIONCLIPREGION
  LAYOUTMODE
  TEXTLANGUAGE
  PUSH
  MAPMODE
SetMapMode(new)
  returning early, identical mode
  PUSH
  CLIPREGION
  PUSH
  ISECTRECTCLIPREGION
  BMPSCALE
  POP
SetMapMode(new)
  returning early, identical mode
  POP
  POP
SetMapMode(new)
  returning early, identical mode
  FILLCOLOR
  LINECOLOR
  RECT
  POP
  POP
  PUSH
  ISECTREGIONCLIPREGION
  POP
  POP
SetMapMode(new)
  setting maMapMode=rNewMapMode at 864
  origin=(0,0) scale=(1/1,1/1) at 889
SetMapMode(new)
  returning early, identical mode
WinSalPrinter::EndPage()


Not OK:
WinSalPrinter::StartPage()
GDIMetaFile::Play (2): nPos=-1 count=55
  PUSH
  MAPMODE
SetMapMode(new)
  returning at 826
  MAPMODE
SetMapMode(new)
  setting maMapMode=rNewMapMode at 864
  origin=(-568,-568) scale=(1/1,1/1) at 889
  LINECOLOR
  FILLCOLOR
  MAPMODE
SetMapMode(new)
  returning early, identical mode
  PUSH
  LINECOLOR
  PUSH
  LINECOLOR
  RECT
  POP
  PUSH
  LINECOLOR
  RECT
  POP
  PUSH
  LINECOLOR
  RECT
  POP
  PUSH
  LINECOLOR
  RECT
  POP
  POP
  PUSH
  PUSH
  ISECTREGIONCLIPREGION
  POP
  POP
  LAYOUTMODE
  PUSH
  PUSH
  ISECTREGIONCLIPREGION
  LAYOUTMODE
  TEXTLANGUAGE
  PUSH
  MAPMODE
SetMapMode(new)
  returning early, identical mode
  PUSH
  CLIPREGION
  PUSH
  ISECTRECTCLIPREGION
  BMPSCALE
  POP
SetMapMode(new)
  returning early, identical mode
  POP
  POP
SetMapMode(new)
  returning early, identical mode
  FILLCOLOR
  LINECOLOR
  RECT
  POP
  POP
  PUSH
  ISECTREGIONCLIPREGION
  POP
  POP
SetMapMode(new)
  setting maMapMode=rNewMapMode at 864
  origin=(0,0) scale=(1/1,1/1) at 889
SetMapMode(new)
  returning early, identical mode
WinSalPrinter::EndPage()
Comment 51 Rainer Bielefeld Retired 2011-07-12 00:26:54 UTC
@Nicolas R:
Your Crash observation seems not to be related, I filed new "Bug 39159 - PRINTING: Switching radio buttons "Selection <-> All" Crashes"
Comment 52 Rainer Bielefeld Retired 2011-07-12 00:45:20 UTC
Worked with former LibO versions.
Comment 53 Don't use this account, use tml@iki.fi 2011-07-12 03:14:42 UTC
Sigh, I now realize that an unknown part of my reproduction successes has actually been bogus: If one has a part of a document "selected", and then File:Print, the idiotic default is that it prints just the selection. I had not noticed that it defaults to printing just the selection. (That is IMHO a horrible feature, but no doubt if we would "fix" it, people would scream how that is an insult to the users, makes LO totally unusable, and especially unsuitable for left-handed people working in the construction industry, or something.)

At the moment I am not capable of reproducing the bug with either my own trivial test document (either the one attached, or a similar one constructed from scratch), or the "Copia de..." sample document. This is with a relatively fresh build of vclmi.dll and swmi.dll from the 3-4 branch, but otherwise stock LibreOffice 3.4.0rc2 (I think). I will now try to reproduce with the latest 3.4.2 beta or something...
Comment 54 Don't use this account, use tml@iki.fi 2011-07-12 03:59:02 UTC
OK, with the 3.4.1 final installed in a VM I can indeed reproduce now again, both with the "Copia de Plantilla"... document (sigh, why can't we have sample documents with *short* and *simple* names?) and with a minimal test case constructed on the fly out of a 1x1 table with an image. (And this time I made sure that I did *not* print just the selection.)

Will now then try to replace the vclmi.dll and/or swmi.dll DLLs with the ones freshly built for debugging and see if the bug goes away...
Comment 55 Don't use this account, use tml@iki.fi 2011-07-12 04:39:41 UTC
Created attachment 48999 [details]
Another minimal test case

Now, with this test case, I definitely see the bug even if I make sure not to have anything selected. Both with 3.4.1 final as such, and with a freshly built vclmi.dll.
Comment 56 Don't use this account, use tml@iki.fi 2011-07-12 04:41:31 UTC
And here is the same kind of debugging output from printing that t.odt, with the table (its borders) not visible in the output:

WinSalPrinter::StartPage()
GDIMetaFile::Play (2): nPos=-1 count=96
  PUSH
  MAPMODE
SetMapMode(new)
  returning at 826
  MAPMODE
SetMapMode(new)
  setting maMapMode=rNewMapMode at 864
  origin=(-3265,-568) scale=(1/1,1/1) at 889
  LINECOLOR
  FILLCOLOR
  MAPMODE
SetMapMode(new)
  returning early, identical mode
  PUSH
  LINECOLOR
  PUSH
  LINECOLOR
  RECT
  POP
  PUSH
  LINECOLOR
  RECT
  POP
  PUSH
  LINECOLOR
  RECT
  POP
  PUSH
  LINECOLOR
  RECT
  POP
  POP
  PUSH
  PUSH
  ISECTREGIONCLIPREGION
  POP
  POP
  PUSH
  CLIPREGION
  TEXTLANGUAGE
  LINECOLOR
  COMMENT
  LINECOLOR
  FILLCOLOR
  POLYLINE
  COMMENT
  TEXTLANGUAGE
  LINECOLOR
  COMMENT
  LINECOLOR
  FILLCOLOR
  POLYLINE
  COMMENT
  TEXTLANGUAGE
  LINECOLOR
  COMMENT
  LINECOLOR
  FILLCOLOR
  POLYLINE
  COMMENT
  TEXTLANGUAGE
  LINECOLOR
  COMMENT
  LINECOLOR
  FILLCOLOR
  POLYLINE
  COMMENT
  POP
  LAYOUTMODE
  FONT
  TEXTALIGN
  TEXTFILLCOLOR
  FONT
  TEXTALIGN
  TEXTFILLCOLOR
  FONT
  TEXTALIGN
  TEXTFILLCOLOR
  LAYOUTMODE
  PUSH
  PUSH
  ISECTREGIONCLIPREGION
  LAYOUTMODE
  TEXTLANGUAGE
  PUSH
  MAPMODE
SetMapMode(new)
  returning early, identical mode
  PUSH
  CLIPREGION
  PUSH
  ISECTRECTCLIPREGION
  BMPSCALE
  POP
SetMapMode(new)
  returning early, identical mode
  POP
  POP
SetMapMode(new)
  returning early, identical mode
  FILLCOLOR
  LINECOLOR
  RECT
  POP
  POP
  PUSH
  ISECTREGIONCLIPREGION
  POP
  POP
SetMapMode(new)
  setting maMapMode=rNewMapMode at 864
  origin=(0,0) scale=(1/1,1/1) at 889
SetMapMode(new)
  returning early, identical mode
WinSalPrinter::EndPage()
Comment 57 tommy27 2011-07-12 04:42:08 UTC
@Tor
thanks for your efforts trying to fix this annoying bug.
I keep my fingers crossed!!!
Comment 58 Don't use this account, use tml@iki.fi 2011-07-12 05:47:11 UTC
However, with a freshly built swmi.dll I don't see the bug. Whether this is because I built it with (partial) debugging, or because of some code changes in it since 3.4.1, no idea...
Comment 59 Don't use this account, use tml@iki.fi 2011-07-12 06:05:33 UTC
I guess it is possible that we are lucky, and some change in the code after 3.4.1 has (accidentally) fixed also this problem...
Comment 60 Rainer Bielefeld Retired 2011-07-12 06:30:21 UTC
@Tor:
What ever that might help for your investigations: I just did a test with my more complex sample documens and compared result 3.4.1 and a Daily 3.4 Branch Dated 2011-07-08. 

I see much progress concerning the table printing, a blue table not printed at all with 3.4.1 now is printed correctly, and also the resting table lines seem to be complete. 

A print with HP OJ3110 looks perfect, also the Drawing object is no longer cropped.

It might be that there still some PS print problems exist. FREEPDF shows some line thickness issues (grey instead of black), and the envelope still is cropped, but in a different way I saw that before. IMHO this is a different issue that had been hidden by the terrible other cropping

Result via Dell PS Printer still looks horrible on screen, some better in print, but same as from OOo 3.1.1, so that is not our problem.

My summary:
Table print problem fixed / worksforme (IMHO we can change status)
Remaining Drawing Cropping problem IMHO different issue, If you do not object, I will file a new report for that.
Comment 61 tommy27 2011-07-12 08:13:08 UTC
@Tor & Reiner

great!!! teamwork pays!!!
Comment 62 manj_k 2011-07-12 08:52:57 UTC
I can confirm Rainer's finding.

Tested with LibO 3.4 Daily
[libreoffice-3-4~2011-07-10_23.10.17_LibO_3.4.1rc1_Win_x86_install_en-US_de_fr.exe
on WinXP]:

1. 't.odt' (Another minimal test case - Attachment 48999 [details])
Works well (with line width 0,50 pt; that's another problem)

2. 'Copia de Plantilla_Defensoria-OpenOffice.ott' (bug 38609, Attachment 48348 [details])
Works well

3. 'header_border_image.odt' (Attachment 48819 [details])
Works well

4. 'sample embedded calc wont print border cells.odt' (bug 37975, Attachment 47590 [details])
Works pretty well (only a left border is missing; probably another problem)
Comment 63 Rainer Bielefeld Retired 2011-07-13 01:58:47 UTC
No objections, so due to latest results I add target and close this one for now.
I will leave comments for follow ups concerning remaining problems with different reasons.
Comment 64 manj_k 2011-07-16 13:25:43 UTC
*** Bug 37867 has been marked as a duplicate of this bug. ***
Comment 65 Cor Nouws 2011-07-18 00:58:02 UTC
great seeing this resolved! Thanks a lot all.

(I missed this earlier, because I'm on vacation and missed too that my subscription to libreoffice-dev list somehowe got broken).

As state/solution I would rather advice just 'fixed'. 
Not only because it was broken (though the reason solution are not spit out), but also beacuse it is much clearer to people looking for the coming 3.4.2 release that this is fixed. Now 37488 does not show on http://dev-builds.libreoffice.org/pre-releases/src/bugfixes-libreoffice-3-4-release-3.4.2.1.log ...
Comment 66 Nicolas R 2011-07-18 01:20:48 UTC
fixed !  Cheers !
Comment 67 Rainer Bielefeld Retired 2011-07-18 01:39:13 UTC
@Cor Nouws:
I prefer the "WORKSFORME" because we can not know how t4h problem has been repaired. For good reasons the Bugzilla Help text for FIXED is "A fix for this bug is checked into the tree and tested." These fixes are very reliable. 
The pseudo-fixes are much less reliable, sometimes the problem reappears. For me it eases the work if my Bugzilla search separates such "real reviewed fixes" from "problem vanished somehow, nobody knows why".
Comment 68 Cor Nouws 2011-07-24 16:45:00 UTC
@rainer:
well, OK, I can agree. I thought setting to 'Fixed' would help to get this kind of automagically resolved issues in the generated list of fixes. But since it does not (as explained to me on the list), I have no reason to stick to my proposal.
Comment 69 Rainer Bielefeld Retired 2011-07-24 22:33:24 UTC
@Cor:
For me information how those lists are created also was nes.
Comment 70 Carlo Strata 2011-08-19 05:24:24 UTC
See also bug 32849.
Comment 71 manj_k 2011-08-25 06:58:06 UTC
*** Bug 37670 has been marked as a duplicate of this bug. ***
Comment 72 Zarko Zivanov 2011-11-09 10:29:40 UTC
I see that this bug was moslty on Windows, but I have a problem with messed-up printing on Ubuntu 11.10 32-bit with LibreOffice 3.4.2. It is a simple text-only document, created in LibreOffice. I don't know if you need sample file for this or not, but the result is far from usable - almost one in 10 words is wrongly printed. If I export document to PDF, and print it, everything looks OK. I also tried the latest 3.4.4 from LibreOffice PPA, but that one prints the same as 3.4.2. Interestingly, if I open the same document in OpenOfice 3.3, and print from it, it looks fine. If you need sample, please tell, I'll send it here.
Comment 73 Zarko Zivanov 2011-11-09 10:35:16 UTC
Hmm, I tought that I was filling the bug for
"[Bug 37488] PRINTING result completely messed up"
but, after sending, I see different title of the bug. If this isn't the right place, should I make a new one?
Comment 74 Rainer Bielefeld Retired 2011-11-09 11:03:31 UTC
@Zarko Zivanov
Summery concerning your Comment 73: this bug can be closed again?
Comment 75 Zarko Zivanov 2011-11-09 13:22:35 UTC
I will file a new bug for my issue, with the same text. Sorry for the inconvinience.
Comment 76 Rainer Bielefeld Retired 2011-11-09 23:10:42 UTC
@Zarko Zivanov
A simple "Yes" would have been enouth ;-)