[gs-bugs] [Bug 698460] - MuPDF - mutool draw -Fpng <filename.png> 1 doesn't send send stream to stdout

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698460

Bug ID: 698460
Summary: mutool draw -Fpng <filename.png> 1 doesn't send send
stream to stdout
Product: MuPDF
Version: master
Hardware: PC
OS: Windows NT
Status: UNCONFIRMED
Severity: normal
Priority: P4
Component: apps
Assignee: mupdf-***@artifex.com
Reporter: ***@onet.pl
QA Contact: gs-***@ghostscript.com
Word Size: ---

"mutool draw -Fpng <filename.pdf> 1" doesn't send the data of first page to
stdout.

I want to use it to draw PDF as PNG and use it with QImage::loadLoadFromData()
(Qt library). The PNG can be raw or base64 encoded - it will be no problem but
here is no output.

I want to stream the PNG to other program without use of hard/SSD drive for
performance reason.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698460

Robin Watts <***@artifex.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@artifex.com

--- Comment #1 from Robin Watts <***@artifex.com> ---
How about:

mutool draw -Fpng -o - <filename.pdf> 1

?

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698460

--- Comment #2 from Robin Watts <***@artifex.com> ---
Also, if performance is your goal, then drive mupdf using the C api for speed
and avoid stdout entirely.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698460

Diana <***@onet.pl> changed:

What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |minor

--- Comment #3 from Diana <***@onet.pl> ---
Is mutool API LGPL and the API works on Windows? Will the commercial
application be LGPL compatible with use of mupdf via API?

Thank you for this workaround. The "-o -" works properly but it looks like a
hack.
For -Fstext it is not needed.

I change priority to "minor" because the effect is possible to trigger via
other command.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698460

--- Comment #4 from Diana <***@onet.pl> ---
After trying use the stream - all \r\n must be converted to \n. For png output
the mode of stdout shall be switched to binary by using set
"setmode(2,O_BINARY);"

Probably only for Windows.
I have read the stream using CreateProcessW and CreatePipe.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698460

--- Comment #5 from Diana <***@onet.pl> ---
* "setmode(1,O_BINARY);"

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698460

--- Comment #6 from Robin Watts <***@artifex.com> ---
(In reply to Diana from comment #3)

Post by b***@artifex.com
Is mutool API LGPL and the API works on Windows? Will the commercial
application be LGPL compatible with use of mupdf via API?

No. All of MuPDF is licensed under the GNU AGPL. The commercial application
would need to be GNu AGPL licensed too.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698460

--- Comment #7 from Diana <***@onet.pl> ---
And here is only one way: CreateProcessW and using of stdout or file output.
Does it is compatible GNU AGPL use?

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698460

--- Comment #8 from Robin Watts <***@artifex.com> ---
(In reply to Diana from comment #7)

Post by b***@artifex.com
And here is only one way: CreateProcessW and using of stdout or file output.
Does it is compatible GNU AGPL use?

This really smells to me like you're trying to couple MuPDF fairly tightly into
your own application. The more tightly coupled you make it, the closer you come
to falling foul of the derivative work terms of the GNU APGL.

Aside from this tight coupling, I wonder if you're setting this up to run on a
server offering a service to other people. The big difference between the GNU
GPLv3 and the GNU AGPL is that the latter specifically recognises "Software As
A Service" installations as "distribution". This would mean that the whole of
your servers software installation would have to be covered by the GNU AGPL.

As such, I think you need to be very careful. We are not lawyers, and it's not
our job to give you legal advice. Certainly, we can't tell you "yes, you're
alright", or "no, you're not".

*You* have the responsibility to read, understand, and abide by the terms of
the GNU AGPL, because you're the one that will be liable if you don't. I'm
sorry that I can't be more help here.

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698460

Robin Watts <***@artifex.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED

--- Comment #9 from Robin Watts <***@artifex.com> ---
I have fixed mutool draw -o - to use a binary stream when appropriate on
windows, in the following commit:

commit 68dd6525d7b4d14b396a86448283dd4b9b625970
Author: Robin Watts <***@artifex.com>
Date: Wed Nov 8 16:58:40 2017 +0000

Bug 698460: Mudraw: Set stdout to binary on windows

[b***@artifex.com]

http://bugs.ghostscript.com/show_bug.cgi?id=698460

--- Comment #10 from Diana <***@onet.pl> ---
(In reply to Robin Watts from comment #8)

Post by b***@artifex.com
This really smells to me like you're trying to couple MuPDF fairly tightly
into your own application. The more tightly coupled you make it, the closer
you come to falling foul of the derivative work terms of the GNU APGL.

The user has possibility to change the tool application in configuration
including path, attributes, format of attributes and format of XML. The mutool
is not included in package and only is recommended as one of positions.
I contacted with your company to get license but... I cannot answer your
questions because I'm FREELANCER, I don't have COMPANY.

Post by b***@artifex.com
Aside from this tight coupling, I wonder if you're setting this up to run on
a server offering a service to other people. The big difference between the
GNU GPLv3 and the GNU AGPL is that the latter specifically recognises
"Software As A Service" installations as "distribution". This would mean
that the whole of your servers software installation would have to be
covered by the GNU AGPL.

No, I do not use this on server. It is not possible via CreateProcessW. The
program do not use TCP/UDP ports for communication. Only CreateProcessW (normal
executing like from CMD.exe) and only stdout data or created files are used.

It is permitted to use exec (or windows alternative: CreateProcessW) to do it.
I DON'T read internal signals/memory of the mutool process.

Post by b***@artifex.com
As such, I think you need to be very careful. We are not lawyers, and it's
not our job to give you legal advice. Certainly, we can't tell you "yes,
you're alright", or "no, you're not".

It is only one way IF YOU DON'T HAVE LICENSES FOR FREELANCERS. More the half of
programmers are FREELANCERS, and they have only one way... Use createProcessW
without server mode, without reading internal signals and give possibility (in
application config) to change the mutool with other application.

Freelancers make mainly small projects and usually they cannot answer most
MANDATORY questions during negotiations of license price.

Post by b***@artifex.com
*You* have the responsibility to read, understand, and abide by the terms of
the GNU AGPL, because you're the one that will be liable if you don't. I'm
sorry that I can't be more help here.

I read the license, I read FAQ about this license.

BTW: Thank you for correcting the error. The application is able to detect
error mode and switch mode automatically.