Vote: make --enable-pango option use cairo-PostScript to output PostScript

[Manolo]

I propose to fix a limitation of our PostScript support where only latin

characters can be output in vectorial form to PostScript. Non-latin scripts

are output in bitmap form.

That is relevant for the X11 platform where FLTK printing uses PostScript.

[That is not important under Windows and macOS because printing

fully supports all of unicode in vectorial form there.]

The solution I propose is to use cairo's PostScript surface, and to activate that

by  "configure --enable-pango" or CMake's OPTION_USE_PANGO.

I attach, as an example, the PostScript output for test/editor and misc/lorem_ipsum.txt

containing all sorts of scripts.

It's all at

    https://github.com/ManoloFLTK/fltk.git

in branch pango-ps

Please, vote about my proposal to commit that to FLTK 1.4.
Thanks.

[Albrecht Schlosser]

On 10/27/20 4:46 PM Manolo wrote:
>
> I propose to fix a limitation of our PostScript support where only latin
> characters can be output in vectorial form to PostScript. Non-latin scripts
> are output in bitmap form.
> That is relevant for the X11 platform where FLTK printing uses PostScript.
> [That is not important under Windows and macOS because printing
> fully supports all of unicode in vectorial form there.]

OK, sounds good.

> The solution I propose is to use cairo's PostScript surface, and to
> activate that
> by  "configure --enable-pango" or CMake's OPTION_USE_PANGO.

Hmm, as I read this, this means that building FLTK with Pango and
(optional) print support will additionally require Cairo (libpangocairo,
IIRC). Is this true?

I think this would be a (kinda) regression that should be avoided. Note
that I disabled libpangocairo on my Linux system (by editing
CMake/options.cmake in a non-standard way, see below) for testing and
this broke the compilation.

Maybe my test failed because it was faulty, but anyway, this needs
clarification. TIA.

> I attach, as an example, the PostScript output for test/editor and
> misc/lorem_ipsum.txt
> containing all sorts of scripts.

Awesome!

> It's all at
>     https://github.com/ManoloFLTK/fltk.git
> in branch pango-ps

Checked out, built, but not yet tested...

> Please, vote about my proposal to commit that to FLTK 1.4.
> Thanks.

Need some testing and, before I vote, I'd like to see the question above
answered. I wouldn't like to have a dependency on Cairo for builds that
don't need it (for instance, using only latin scripts).

[Ian MacArthur]

On 27 Oct 2020, at 19:09, Albrecht Schlosser wrote:
>
> On 10/27/20 4:46 PM Manolo wrote:
>> I propose to fix a limitation of our PostScript support where only latin
>> characters can be output in vectorial form to PostScript. Non-latin scripts
>> are output in bitmap form.
>> That is relevant for the X11 platform where FLTK printing uses PostScript.
>> [That is not important under Windows and macOS because printing
>> fully supports all of unicode in vectorial form there.]
>
> OK, sounds good.
>
>> The solution I propose is to use cairo's PostScript surface, and to activate that
>> by "configure --enable-pango" or CMake's OPTION_USE_PANGO.
>
> Hmm, as I read this, this means that building FLTK with Pango and (optional) print support will additionally require Cairo (libpangocairo, IIRC). Is this true?

I’m (generally) in favour of this mechanism, though I take Albrecht’s point that adding a dependency on Cairo may not be ideal... The output looks good, and the additional print support it brings is useful.


Is there some scheme whereby we get the current behaviour for builds *with* print support but *without* Cairo, and this improved behaviour for builds with both print support and Cairo enabled?

How complex is that?

[Greg Ercolano]

On 2020-10-27 08:46, Manolo wrote:

I attach, as an example, the PostScript output for test/editor and misc/lorem_ipsum.txt

containing all sorts of scripts.

    And here's a PNG conversion (@300dpi/24 color) of that FLTK+cairo.ps file,
    for those that might not have a postscript reader.

[Albrecht Schlosser]

On 10/27/20 8:09 PM Albrecht Schlosser wrote:
>
> Hmm, as I read this, this means that building FLTK with Pango and
> (optional) print support will additionally require Cairo (libpangocairo,
> IIRC). Is this true?
>
> I think this would be a (kinda) regression that should be avoided. Note
> that I disabled libpangocairo on my Linux system (by editing
> CMake/options.cmake in a non-standard way, see below) for testing and
> this broke the compilation.

Forgot to attach my CMake mods:

diff --git a/CMake/options.cmake b/CMake/options.cmake
index 2bb439ae6..fa87798e6 100644
--- a/CMake/options.cmake
+++ b/CMake/options.cmake
@@ -463,7 +463,7 @@ endif (OPTION_USE_PANGO)
#######################################################################
if (X11_Xft_FOUND AND OPTION_USE_PANGO)
pkg_check_modules(PANGOXFT pangoxft)
- pkg_check_modules(PANGOCAIRO pangocairo)
+ pkg_check_modules(PANGOCAIRO pangocairoXXX)
pkg_check_modules(CAIRO cairo)
# message (STATUS "PANGOXFT_FOUND=" ${PANGOXFT_FOUND})
if (PANGOXFT_FOUND AND PANGOCAIRO_FOUND AND CAIRO_FOUND)


Intention is to simulate that libpangocairo is not available (w/o
deinstalling or renaming of system files).

[Manolo]

Thanks to all for these first replies.

Yes, in principle, it's possible to add OPTION_USE_CAIROPS as a new build (or configure)

option. But my feeling, at this point, is that this would not correspond to real-life situations because:

- OPTION_USE_PANGO requires package libpango-1.0-dev to get both libpango-1.0.so

and pango-related include files. In Debian and Ubuntu, that package includes libpangocairo-1.0.so .

Thus, when OPTION_USE_PANGO's requirements are satisfied, libpangocairo-1.0.so is also there,

at least with Debian/Ubuntu.

- OPTION_USE_PANGO makes sense for apps that potentially handle not-Latin characters.
It seems logical that FLTK give them vectorial printing support at the same time.

- If OPTION_USE_PANGO is not activated, the usual PostScript driver remains in the code which

gives full printing support, except it draws non-Latin characters in bitmap form.

P.S. I found okular, and its "Import PS file" command, useful to display .ps files under Debian.

[imm]

On Wed, 28 Oct 2020 at 07:23, Manolo <manol...@gmail.com> wrote:
>
> - If OPTION_USE_PANGO is not activated, the usual PostScript driver remains in the code which
> gives full printing support, except it draws non-Latin characters in bitmap form.
>

Ah - I had missed that...
I think that mostly addresses my concerns then, as we will fall back
to the "legacy" behaviour if pango is not enabled...
On Linux, I pretty much always have pango enabled in 1.4 builds
anyway, so I had not really grasped that was what would happen.

So, a user that builds *without* pango enabled will get the "legacy"
postscript support, and no new dependency is introduced.

A user who builds *with* pango enabled will get the improved
postscript support, and potentially added dependency on libs that can
be assumed to be present if pango is present.

Is that a reasonable statement?

If so then I am in favour of this enhancement.

[imm]

On Wed, 28 Oct 2020 at 07:23, Manolo wrote:
>
> P.S. I found okular, and its "Import PS file" command, useful to display .ps files under Debian.
>

Meant to say - I didn't realise that viewing PS files was a problem;
Ubuntu ships with Evince installed by default, which has always Just
Worked for me, and on the Mac Preview seems to open PS files OK too.
I don't seem to have a PS viewer on Windows though, now I try it...

[Albrecht Schlosser]

On 10/28/20 8:23 AM Manolo wrote:
> Thanks to all for these first replies.

Welcome

> Yes, in principle, it's possible to add OPTION_USE_CAIROPS as a new
> build (or configure) option.

BTW: my point was not to add a new option but to fall back sensibly if
Cairo is not available. But that's now moot, see below.

> But my feeling, at this point, is that this would not correspond
> to real-life situations because:
>
> - OPTION_USE_PANGO requires package libpango-1.0-dev to get both
> libpango-1.0.so
> and pango-related include files. In Debian and Ubuntu, that package
> includes libpangocairo-1.0.so .
> Thus, when OPTION_USE_PANGO's requirements are satisfied,
> libpangocairo-1.0.so is also there,
> at least with Debian/Ubuntu.

Yep, thanks for that info. I verified that (on my Linux Mint - based on
Ubuntu) libpango1.0-dev explicitly depends on libcairo2-dev and
libpangocairo-1.0-0 which removes my concerns. Hence...

+1 on this awesome improvement

and many thanks for your continuing great work on such additions!

> P.S. I found okular, and its "Import PS file" command, useful to display
> .ps files under Debian.

As Ian wrote I never had problems viewing .ps files on Linux. Mint comes
with `xreader' which opens .ps and .pdf files and, as Ian wrote,
`evince' which is now a symbolic link to `xreader':

$ file /usr/bin/evince
/usr/bin/evince: symbolic link to /usr/bin/xreader

[imm]

On Wed, 28 Oct 2020 at 12:36, Albrecht Schlosser wrote:
>
> > P.S. I found okular, and its "Import PS file" command, useful to display
> > .ps files under Debian.
>
> As Ian wrote I never had problems viewing .ps files on Linux. Mint comes
> with `xreader' which opens .ps and .pdf files and, as Ian wrote,
> `evince' which is now a symbolic link to `xreader':
>
> $ file /usr/bin/evince
> /usr/bin/evince: symbolic link to /usr/bin/xreader
>

Huh, that must be a Mint thing, I think. Under Ubuntu, evince is evince...

[Albrecht Schlosser]

Maybe yes, but which Ubuntu version? Current Mint (20) is based on
Ubuntu 20.04 LTS. Do you have an older version?

[gga]

El 28/10/20 a las 10:15, Albrecht Schlosser escribió:

> Maybe yes, but which Ubuntu version? Current Mint (20) is based on
> Ubuntu 20.04 LTS. Do you have an older version?
>

No, that is true of Ubuntu 20.04.1 at least.

--
Gonzalo Garramuño

[Manolo]

On Wednesday, October 28, 2020 at 12:07:51 PM UTC+1 imacarthur wrote:

So, a user that builds *without* pango enabled will get the "legacy"
postscript support, and no new dependency is introduced.

A user who builds *with* pango enabled will get the improved
postscript support, and potentially added dependency on libs that can
be assumed to be present if pango is present.

Is that a reasonable statement?

Yes, absolutely.

If so then I am in favour of this enhancement.

Counting this as a +1 vote and with Albrecht's +1, and mine (implicit), I have

committed the new code to git (8accc6e8409819316fa296642c1d23e5638fcb2d).