Bug 160848 - Writer "convert-to pdf" is now outputting unsuppressable debug lines
Summary: Writer "convert-to pdf" is now outputting unsuppressable debug lines
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-04-28 14:07 UTC by Bernard Moreton
Modified: 2024-04-29 14:56 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernard Moreton 2024-04-28 14:07:04 UTC
Description:
(soffice --headless --convert-to pdf:writer_pdf_Export --outdir /tmp FILENAME.rtf) >/dev/null 2>&1

when called from within a BASH script now produces output such as:
convert /tmp/IV-ms9756.rtf as a Writer document -> /tmp/IV-ms9756.pdf using filter : writer_pdf_Export

This output was always present, but used to be suppressed by >/dev/null 2>&1
- but this no longer (since LO 24.x ?) has any effect.

The output is not necessarily in the Gnome-terminal tab that the command is running in - may be in the tab in which LO was first called??

When called from the command line, it does not appear to produce this output;
and on first call from the script also I have not *seen* such output.

Is it now on a different output from STDOUT and STDERR ??

When running without the redirections, and from the command line, I get:
$ (soffice --headless --convert-to pdf:writer_pdf_Export --outdir /tmp IV-ms9756.rtf)
convert /tmp/IV-ms9756.rtf as a Writer document -> /tmp/IV-ms9756.pdf using filter : writer_pdf_Export
Overwriting: /tmp/IV-ms9756.pdf

From the script, with the redirections, this output is not suppressed.
Before LO 24.x it used to be.
If the output is in a different Terminal tab, it's not a problem,
but if it outputs to the current tab it messes the screen considerably.

I can't give an easy way to reproduce atm, though I'll try to rejig my script appropriately...
In the meantime, I hope the output messages give a clear indication of what's going wrong!




Steps to Reproduce:
1.Run my script - but I need to make this uploadable
2.
3.

Actual Results:
convert /tmp/IV-ms9756.rtf as a Writer document -> /tmp/IV-ms9756.pdf using filter : writer_pdf_Export
in current Terminal tab, or in another

Expected Results:
None - the output should be suppressed with ./dev/null 2>&1


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 24.2.2.2 (X86_64) / LibreOffice Community
Build ID: 420(Build:2)
CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-GB
Ubuntu package version: 4:24.2.2~rc2-0ubuntu0.22.04.1~lo1
Calc: threaded
Comment 1 Julien Nabet 2024-04-29 10:59:08 UTC
On pc Debian testing with LO Debian package 24.2.0.3, I don't reproduce this.

I created a file called FILENAME.rtf containing:
{\rtf1\ansi
 {\fonttbl
    {\f0\fnil\fcharset0\fprq0\fttruetype Helvetica;}
    {\f1\fnil\fcharset0\fprq0\fttruetype Bitstream Charter;}
 }
 {\f1\fs24 Ceci est un texte accentu\'e9}
 \par
 {\f0\fs24 avec des caract\'e8res {\b gras},} 
 \par
 {\f1 des {\fs18 petits} et des {\fs32 gros}.} 
 }
then:
(soffice --headless --convert-to pdf:writer_pdf_Export --outdir /tmp FILENAME.rtf) >/dev/null 2>&1
no output.
Comment 2 Bernard Moreton 2024-04-29 13:28:08 UTC
 Thank you, Julien.

On testing today, I get different results from yesterday - but then I was calling my script yesterday from a 4GL application, which I'm not today.

The problem yesterday seemed to be lined to a redundant '}' at the end of the rtf, following the RTF end-of-document closure.  Taking that out seemed yesterday to remove the unwanted output, consistently.

I'll simplify the LO call for convert-to, leaving out the --headless and --outdir, which seemed necessary to have in some years ago, but which don't seem to do anything significant for my purposes now;  and instead of calling my script, make three separate BASH calls from my 4GL app.

And all this to check on exactly how many lines a variable message will take up on a document, so's to keep everything on a single page 
(write the lines to a temporary RTF with the appropriate typeface and formatting convert to PDF; 
call pdftotext -layout -nopgbrk; 
count the lines (wc -l); 
then add the appropriate number of blank lines to the main document in the $GL app, to get the layout correct).

What I do notice today in the course of testing is that if I remove the RTF end-of-document closing brace (}), then "convert-to pdf" outputs "Error: source file could not be loaded" - but returns an exit code of 0 !
Comment 3 Julien Nabet 2024-04-29 14:56:32 UTC
Good for you! :-)

Since there wasn't any bug per se, let's rather put this one as WFM.