Description: Since upgrade to 6.1.0.3 printing stopped working properly. All text is missing. Images and table boundaries are printed. * Tried a few text fonts, but none printed. * Used to work fine. * As a workaround, one can export to PDF and print. Steps to Reproduce: Create Text or spreadsheet. Print. (Can only test postscript printers for now) Actual Results: Both in the (postscript) printer, and the print-to-file output file, text is absent. Images and table boundaries are printed. Inspection of the postscript file, appears to show that text was not exported at all! Expected Results: Text should be printed Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 144281 [details] example text document
Created attachment 144282 [details] Postscript output (table boundaries only; text missing)
I would like to rule out that it is a CUPS or QT problem. So far I have not seen this bug in other applications, but how can I be sure?
Created attachment 144311 [details] rendering ok I tried to test this bug in 6.1.1. As you can see is a good rendering to printing, and also good rendering at export to PDF. Version: 6.1.1.0.0+ Build ID: 5a56b72413d5f555c854e36d3bd2fd50ec21644c CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-6-1, Time: 2018-08-15_02:45:13 Locale: ro-RO (ro_RO.UTF-8); Calc: group threaded
I tried to bibisect this bug in 6.1. I have this https://pastebin.com/2zA63nTS NOte: When I give "git bisect bad" was because of the errors in the terminal, not because of rendering on Libre Office. The rendering was everytime ok.
Thanks for checking! Do you think that it is a problem on my side? I find it odd that postscript output is wrong, but PDF is fine. How to check further?
Try this https://wiki.documentfoundation.org/UserProfile Or, after that uninstall Libre Office. And install a stable version again. 6.0.6 maybe.
Thanks Bogdan, I'll try that. BTW did you make sure to produce PS and not PDF output? It can be selected in the dialogue that comes up after clicking 'print to file'. Depending on user(!) the default is different.
You have right. I clicked on GP just to show you the render is ok. The PDF was created from Export to PDF. I wanted to be sure that all the method give the same result: screen, GP, PDF.
I reverted back to 6.0.6. All is fine there.
Hello, i have the same problem (Bug 119357). (I use openSUSE 13.2 (x86_64) and LO-6.1.0.3). Absolute the same behaviour. I can confirm, that the .ps-File does not contain any font-information. I compared print-output (produced from LO-6.1.0.3 and LO 6.0.1.1). 3c3 < %%Creator: (LibreOffice 6.0.1.1) --- > %%Creator: (LibreOffice 6.1.0.3) 5c5 < %%CreationDate: (2018-08-21 11:23:19 ) --- > %%CreationDate: (2018-08-21 11:04:18 ) 101,2605d100 < %%BeginResource: font Arial-BoldMTFID34HGSet2 < %!PS-TrueTypeFont-1.0-5.13107 < %%Creator: SunTypeTools-TT 1.0 gelf < %- Font subset generated from a source font file: '/home/uli/.fonts/a/arialbd.ttf' < %- Original font name: Arial-BoldMT < %- Original font family: Arial < %- Original font sub-family: Bold < 11 dict begin < /FontName (Arial-BoldMTFID34HGSet2) cvn def < /PaintType 0 def < /FontMatrix [1 0 0 1 0 0] def < /FontBBox [-627 -376 2000 1017] def < /FontType 42 def < /Encoding 256 array def < 0 1 255 {Encoding exch /.notdef put} for < Encoding 1 /glyph1 put : : Perhaps this Info can help? Thanks for checking.
Thanks for confirming ! Good to see that is also on SUSE.
Bogdan, which linux flavour did you use?
Please test with current master from https://dev-builds.libreoffice.org/daily/master/ and report.
(In reply to Mark van Rossum from comment #13) > Bogdan, which linux flavour did you use? At home I use Ubuntu Budgie 18.04.
I tested now on Windows: Print ok on Version: 6.1.0.3 (x64) Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1 CPU threads: 4; OS: Windows 10.0; UI render: GL; Locale: ro-RO (ro_RO); Calc: group threaded Print ok on: Version: 6.2.0.0.alpha0+ (x64) Build ID: ac7a655f614175353445d99e8550b66936613c21 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-08-14_02:18:26 Locale: ro-RO (ro_RO); Calc: threaded
On bibisect on 6.0 I get this error every time I run the programm, but the programm works ok for me, the text is generated on screen and also on previewand in generated file. "(soffice:8669): Gtk-CRITICAL **: 23:57:29.652: gtk_widget_queue_draw_area: assertion 'height >= 0' failed"
After bibisecting 6.0, and no problem at rendering this is: 0d270e6a18111d2319732b1ac105b52060a9fd79 is the first bad commit commit 0d270e6a18111d2319732b1ac105b52060a9fd79 Author: Jenkins Build User <tdf@pollux.tdf> Date: Wed Jun 6 19:41:14 2018 +0200 source c6c82096301180cfa7942dd9fb9d1cb66c7ecc04 source c6c82096301180cfa7942dd9fb9d1cb66c7ecc04 :040000 040000 f02ee51499fbf9886b95a6e904a50407b5daa96a 383f713e0b96959422b2f04ae907e39f5588ae08 M instdir Now I will try 6.1. I hope I will get the error now... And indeed here is the problem. Half were bad and half were good. ab9eb064445c608105ceb79701289eca241a77a5 is the first bad commit commit ab9eb064445c608105ceb79701289eca241a77a5 Author: Jenkins Build User <tdf@pollux.tdf> Date: Wed Jan 24 08:46:59 2018 +0100 source de8f6b25de6fbe813fe172542e7eff1596b37335 source de8f6b25de6fbe813fe172542e7eff1596b37335 :040000 040000 992100269180bcf5763d53a7c6baf20b7c59637f 6affcc7ed1559f1974deb7ef4e88ac54a98dbd84 M instdir
Everything I tested at previous comment was tested with the result after "Print to File...".
(In reply to BogdanB from comment #17) > On bibisect on 6.0 I get this error every time I run the programm, but the > programm works ok for me, the text is generated on screen and also on > previewand in generated file. > > "(soffice:8669): Gtk-CRITICAL **: 23:57:29.652: gtk_widget_queue_draw_area: > assertion 'height >= 0' failed" I think this is harmless. I have seen it many times from various applications.
(In reply to Mark van Rossum from comment #20) > (In reply to BogdanB from comment #17) > > On bibisect on 6.0 I get this error every time I run the programm, but the > > programm works ok for me, the text is generated on screen and also on > > previewand in generated file. > > > > "(soffice:8669): Gtk-CRITICAL **: 23:57:29.652: gtk_widget_queue_draw_area: > > assertion 'height >= 0' failed" > > I think this is harmless. I have seen it many times from various > applications. Yep, don't worry about that message in the terminal....
I do confirm printing to postscript is a regression from https://cgit.freedesktop.org/libreoffice/core/commit/?id=de8f6b25de6fbe813fe172542e7eff1596b37335 author Noel Grandin <noel.grandin@collabora.co.uk> 2018-01-22 15:52:16 +0200 committer Noel Grandin <noel.grandin@collabora.co.uk> 2018-01-24 07:56:01 +0100 commit de8f6b25de6fbe813fe172542e7eff1596b37335 (patch) tree 4a2864c87395463391cd2ad40c4f1ada962f44e9 parent 182a3c7e12a0f56d664deaf67d17bc51eef6299d (diff) loplugin:unused-returns in vcl Bisected with: bibisect-linux64-6.1 Adding Cc: to Noel Grandin
Patch in gerrit: https://gerrit.libreoffice.org/#/c/59493/1
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4a58fd0e81b0375c71f6182233f0ec9390942cd1 tdf#119357 add the glyph, if the lookup failed It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8d49069887443c9eeac9c52441ad1a183d12c384&h=libreoffice-6-1 tdf#119357 add the glyph, if the lookup failed It will be available in 6.1.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I can confirm that the daily build of 6.1.1 dev fixed this issue (tested on Mx Linux 17.1 and Linux Mint 18.3), and an another issue seen in 6.0.6 version that accented characters are printed as square characters.
(In reply to dxt.tfg from comment #26) > I can confirm that the daily build of 6.1.1 dev fixed this issue (tested on > Mx Linux 17.1 and Linux Mint 18.3), and an another issue seen in 6.0.6 > version that accented characters are printed as square characters. Thanks for checking it in LibreOffice 6.1.1. Setting to VERIFIED FIXED
Text is now printed, but spacing is off. (see sample) Again only in PS not in PDF. I vaguely remember seeing another bug report somewhere on this.
Created attachment 144537 [details] Output with 1:6.1.1~rc1-1
Ok, so bug 119454 remains in 6.1.1