[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LilyPond's gs console output on windows
From: |
Werner LEMBERG |
Subject: |
Re: LilyPond's gs console output on windows |
Date: |
Fri, 23 Aug 2019 06:32:44 +0200 (CEST) |
>> >> I know wonder whether this problem is
>> >>
>> >> (1) limited to the gs program that comes with lilypond,
>> >> (2) related to the way gub is compiling gs,
>> >> (3) connected to changes in the Windows 10 console,
>> >> (4) or whether this a generic issue with gs itself, probably
>> >> fixed in newer gs versions.
>> >>
>> >> If we will have this behaviour with the next gub build also, I
>> >> suggest that it gets documented.
>>
>> Didn't Windows require something like rungs or mgs or gswin32c or
>> so?
>
> I have LilyPond 2.19.83 on Windows 7 Pro 64-bit SP1 and Windows 10
> Pro 64-bit version 1903.
>
> Both of them behave the same way on Windows console: output a blank
> line and exit.
>
> But, with Windows Subsystem for Linux, one can type "bash" in the
> console and it switches to a bash environment. That seems to
> execute things as expected. I haven't tried Git on Windows' bash
> shell.
Thanks for testing; git's bash shell works just fine.
It seems this is a GUB issue: It doesn't set the proper flag(s) to
build gs on windows as a console application. In other words, right
now GUB builds `gswin32' and not `gswin32c'. Maybe this is
intentional – I'm no expert on the Windows setup of GS. If it is, we
should document that calling gs on the Windows console directly only
works if stdout gets redirected to a file, or if the binary is used
within a Unix shell like `git bash'.
Werner
PS: The reason to call gs manually is to benefit from lilypond's
`-dgs-never-embed-fonts' switch (also provided by lyluatex's
`optimize-pdf' option), which needs post-processing with
ghostscript.