Am 19.06.2020 um 18:48 schrieb Jonas Hahnfeld via Discussions on
LilyPond development:
Am Freitag, den 19.06.2020, 16:31 +0200 schrieb Han-Wen Nienhuys:
Thanks; yours is much nicer.
Meanwhile, mine is failing for unknown reasons.
How does this thing work?
make doc
=>
# Making input/regression
Am Freitag, den 19.06.2020, 16:31 +0200 schrieb Han-Wen Nienhuys:
> Thanks; yours is much nicer.
>
> Meanwhile, mine is failing for unknown reasons.
>
> How does this thing work?
>
> make doc
> =>
> # Making input/regression/out-www/collated-files.pdf < texi
> TEX=/home/hanwen/vc/lilypond/script
Thanks; yours is much nicer.
Meanwhile, mine is failing for unknown reasons.
How does this thing work?
make doc
=>
# Making input/regression/out-www/collated-files.pdf < texi
TEX=/home/hanwen/vc/lilypond/scripts/build/xetex-with-options.sh
PDFTEX=/home/hanwen/vc/lilypond/scripts/build/xetex-with
Am Freitag, den 19.06.2020, 15:36 +0200 schrieb Jonas Hahnfeld:
> Am Freitag, den 19.06.2020, 15:11 +0200 schrieb Jonas Hahnfeld:
> > Am Freitag, den 19.06.2020, 14:49 +0200 schrieb Han-Wen Nienhuys:
> > > [hanwen@t460-wlan lilypond]$ qpdf --qdf --object-streams=disable
> > > broken2.pdf /dev/stdou
Han-Wen Nienhuys writes:
> On Fri, Jun 19, 2020 at 3:13 PM David Kastrup wrote:
>>
>> Han-Wen Nienhuys writes:
>>
>> > On Fri, Jun 19, 2020 at 12:50 PM Jonas Hahnfeld wrote:
>> >> No changes for me. Please also keep in mind that the same command
>> >> string works via the API interpreter. It c
On Fri, Jun 19, 2020 at 3:13 PM David Kastrup wrote:
>
> Han-Wen Nienhuys writes:
>
> > On Fri, Jun 19, 2020 at 12:50 PM Jonas Hahnfeld wrote:
> >> No changes for me. Please also keep in mind that the same command
> >> string works via the API interpreter. It could be that this is related
> >> t
Am Freitag, den 19.06.2020, 15:11 +0200 schrieb Jonas Hahnfeld:
> Am Freitag, den 19.06.2020, 14:49 +0200 schrieb Han-Wen Nienhuys:
> > On Fri, Jun 19, 2020 at 12:50 PM Jonas Hahnfeld wrote:
> > > No changes for me. Please also keep in mind that the same command
> > > string works via the API inte
Han-Wen Nienhuys writes:
> On Fri, Jun 19, 2020 at 12:50 PM Jonas Hahnfeld wrote:
>> No changes for me. Please also keep in mind that the same command
>> string works via the API interpreter. It could be that this is related
>> to processing other files before the "empty" one...
>> I'll try to w
Am Freitag, den 19.06.2020, 14:49 +0200 schrieb Han-Wen Nienhuys:
> On Fri, Jun 19, 2020 at 12:50 PM Jonas Hahnfeld wrote:
> > No changes for me. Please also keep in mind that the same command
> > string works via the API interpreter. It could be that this is related
> > to processing other files
On Fri, Jun 19, 2020 at 2:49 PM Han-Wen Nienhuys wrote:
> This does present a quandary, because we'd either have to find
> configuration that causes the problem to go away, or we have to modify
> the string we're executing if we're not using the API.
>
> But the latter undoes the benefit of unifyi
On Fri, Jun 19, 2020 at 12:50 PM Jonas Hahnfeld wrote:
> No changes for me. Please also keep in mind that the same command
> string works via the API interpreter. It could be that this is related
> to processing other files before the "empty" one...
> I'll try to write a small wrapper around the A
On Fri, Jun 19, 2020 at 1:01 PM Han-Wen Nienhuys wrote:
>
> It looks like this was discussed here:
>
> https://github.com/CTeX-org/forum/issues/29
>
> (it's in Chinese, but google translate does a good job on the text.)
>
> According to the report, it's a bug in xdvipdfmx, and the blank pdf
> file
On Fri, Jun 19, 2020 at 12:50 PM Jonas Hahnfeld wrote:
>
> Am Freitag, den 19.06.2020, 12:18 +0200 schrieb Han-Wen Nienhuys:
> > On Fri, Jun 19, 2020 at 12:11 PM David Kastrup wrote:
> > > Jonas Hahnfeld via Discussions on LilyPond development
> > > writes:
> > >
> > > > Am Freitag, den 19.06.20
It looks like this was discussed here:
https://github.com/CTeX-org/forum/issues/29
(it's in Chinese, but google translate does a good job on the text.)
According to the report, it's a bug in xdvipdfmx, and the blank pdf
file is within spec.
I looked at epdf.c, but there was no change in the las
Am Freitag, den 19.06.2020, 12:18 +0200 schrieb Han-Wen Nienhuys:
> On Fri, Jun 19, 2020 at 12:11 PM David Kastrup wrote:
> > Jonas Hahnfeld via Discussions on LilyPond development
> > writes:
> >
> > > Am Freitag, den 19.06.2020, 11:47 +0200 schrieb Han-Wen Nienhuys:
> > > > On Thu, Jun 18, 202
On Fri, Jun 19, 2020 at 12:11 PM David Kastrup wrote:
>
> Jonas Hahnfeld via Discussions on LilyPond development
> writes:
>
> > Am Freitag, den 19.06.2020, 11:47 +0200 schrieb Han-Wen Nienhuys:
> >> On Thu, Jun 18, 2020 at 7:45 PM Jonas Hahnfeld wrote:
> >> > Am Donnerstag, den 18.06.2020, 11:2
Jonas Hahnfeld via Discussions on LilyPond development
writes:
> Am Freitag, den 19.06.2020, 11:47 +0200 schrieb Han-Wen Nienhuys:
>> On Thu, Jun 18, 2020 at 7:45 PM Jonas Hahnfeld wrote:
>> > Am Donnerstag, den 18.06.2020, 11:21 -0600 schrieb Carl Sorensen:
>> > > is it the difference between a
Am Freitag, den 19.06.2020, 11:47 +0200 schrieb Han-Wen Nienhuys:
> On Thu, Jun 18, 2020 at 7:45 PM Jonas Hahnfeld wrote:
> > Am Donnerstag, den 18.06.2020, 11:21 -0600 schrieb Carl Sorensen:
> > > is it the difference between an output .ps file and an output .eps file?
> >
> > No, broken.ps file
On Thu, Jun 18, 2020 at 7:45 PM Jonas Hahnfeld wrote:
>
> Am Donnerstag, den 18.06.2020, 11:21 -0600 schrieb Carl Sorensen:
> > On Thu, Jun 18, 2020 at 11:04 AM Jonas Hahnfeld via Discussions on
> > LilyPond development wrote:
> > > Am Donnerstag, den 18.06.2020, 00:23 +0200 schrieb Valentin Vill
Am Donnerstag, den 18.06.2020, 19:03 +0200 schrieb Jonas Hahnfeld via
Discussions on LilyPond development:
> I think the way forward for now is reverting above commit, even if I
> don't really like it. Unless somebody has a really clever idea how to
> 1) avoid GS producing a broken PDF (if that's t
Am Donnerstag, den 18.06.2020, 11:21 -0600 schrieb Carl Sorensen:
> On Thu, Jun 18, 2020 at 11:04 AM Jonas Hahnfeld via Discussions on
> LilyPond development wrote:
> > Am Donnerstag, den 18.06.2020, 00:23 +0200 schrieb Valentin Villenave:
> > > On 6/17/20, Valentin Villenave wrote:
> > > > `make
Am Donnerstag, den 18.06.2020, 19:03 +0200 schrieb Jonas Hahnfeld via
Discussions on LilyPond development:
> Am Donnerstag, den 18.06.2020, 00:23 +0200 schrieb Valentin Villenave:
> > On 6/17/20, Valentin Villenave wrote:
> > > `make doc’ has been broken for nearly a week on my system (even with a
On Thu, Jun 18, 2020 at 11:04 AM Jonas Hahnfeld via Discussions on
LilyPond development wrote:
>
> Am Donnerstag, den 18.06.2020, 00:23 +0200 schrieb Valentin Villenave:
> > On 6/17/20, Valentin Villenave wrote:
> > > `make doc’ has been broken for nearly a week on my system (even with a
> > > cl
Am Donnerstag, den 18.06.2020, 00:23 +0200 schrieb Valentin Villenave:
> On 6/17/20, Valentin Villenave wrote:
> > `make doc’ has been broken for nearly a week on my system (even with a
> > clean git clone), with the following error:
> >
> > xdvipdfmx:fatal: typecheck: Invalid object type: -1 7 (
> Where can I find the source code for xdvipdfmx?
Here:
https://www.tug.org/svn/texlive/trunk/Build/source/texk/dvipdfm-x/
This is the code for a binary that gets stored under five different
names (either as links or as exact copies):
xdvipdfmx
dvipdfm
dvipdfmx
ebb
extractbb
The bi
> Git bisect actually tells me that xdvipdfmx started misbehaving from
> the same commit that caused gs issues:
>
> 017927b4d63c317e1fc450be2537ccc058072538 (HEAD)
> Author: Han-Wen Nienhuys
> Date: Fri Jun 5 20:36:42 2020 +0200
> Unify calling convention for command-line and API G
On 6/17/20, Valentin Villenave wrote:
> `make doc’ has been broken for nearly a week on my system (even with a
> clean git clone), with the following error:
>
> xdvipdfmx:fatal: typecheck: Invalid object type: -1 7 (line 2161)
Git bisect actually tells me that xdvipdfmx started misbehaving from
t
On 6/17/20, Werner LEMBERG wrote:
> I suggest upgrading. The current maintainer of xdvipdfmx fixes bugs
> in TeXLive directly – however, this doesn't automatically update the
> binaries that are in TeXLive's SVN repository. It's not that
> complicated to get the TeXLive sources and compile a pri
>> It seems that you probably have to update your TeX system...
>
> Update or downgrade?
I suggest upgrading. The current maintainer of xdvipdfmx fixes bugs
in TeXLive directly – however, this doesn't automatically update the
binaries that are in TeXLive's SVN repository. It's not that
complic
Hi,
Le 17/06/2020 à 09:53, Valentin Villenave a écrit :
Hey everybody,
`make doc’ has been broken for nearly a week on my system (even with a
clean git clone), with the following error:
No clue what your problem is, but as an aside, I can give a hint:
instead of a fresh git clone (which must ha
On 6/17/20, Werner LEMBERG wrote:
> It seems that you probably have to update your TeX system...
Update or downgrade? I’m using the latest fc32 repos. Besides, I
haven’t changed anything on my OS recently and this started happening
only a week or so ago; isn’t it possible that this is triggered
> xdvipdfmx:fatal: typecheck: Invalid object type: -1 7 (line 2161)
>
> This is on a Fedora system with xdvipdfmx 20190225 and gs 9.52.
It seems that you probably have to update your TeX system...
https://tex.stackexchange.com/questions/490616/xdvipdfmx-typecheck-problem
If this is not a fe
Hey everybody,
`make doc’ has been broken for nearly a week on my system (even with a
clean git clone), with the following error:
Making input/regression/out-www/collated-files.list < 1368 files
Making input/regression/out-www/collated-files.texi < tely
Making input/regression/out-www/collated-fil
33 matches
Mail list logo