bugGNU Octave - Bugs: bug #55916, pdfTeX warnings in build: found...

 
 

bug #55916: pdfTeX warnings in build: found PDF version <1.7>, but at most version <1.5> allowed

Submitted by:  Andrew Janke <apjanke>
Submitted on:  Thu 14 Mar 2019 09:37:10 AM UTC  
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  Mac OS

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Fri 29 Mar 2019 03:11:36 PM UTC, comment #19: 

As this seems to have disappeared, I'm going to close the report.  There are plenty of more pressing bug reports to work on for Mac OS.

Rik <rik5>
Project Administrator
Fri 29 Mar 2019 01:49:32 AM UTC, comment #18: 

> Looking in your log, there appears to be much trouble constructing the pdf files.


This is due to bug #55268. It happens all the time if I don't include the patch from that issue.

> Finally, last option is to let sleeping dogs lie. If the warning has gone away, great. Maybe it was just gremlins.


I'm fine with that. It really does seem to be gone.

Andrew Janke <apjanke>
Thu 28 Mar 2019 03:48:02 PM UTC, comment #17: 

So, if the problem is that pdftex is producing warnings on 1.7 files, then there shouldn't be an issue on Andrew's machine, because an ordinary print command is generating 1.5 version files.

I wonder if there was leftover cruft, for example, an install of documentation files from a tar.gz file that were made at version 1.7.  These files wouldn't need to be re-created by the build system so they would persist, but they would cause a warning whenever you tried to build octave.pdf which runs pdftex.

In that case, clearing out all of the documentation with "make maintainer-clean" and starting over with "autogen.sh; configure; make" should sort it out.

I don't know whether there is a way to for software rendering on MacOS.

Rik <rik5>
Project Administrator
Thu 28 Mar 2019 03:36:47 PM UTC, comment #16: 

'invalid framebuffer operation' seems to me the culprit.

I forgot, is it possible to force software OpenGL renderer on MacOS?

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Thu 28 Mar 2019 03:23:34 PM UTC, comment #15: 

pdfinfo doc/interpreter/convhull.pdf
Title:          gl2ps_renderer figure
Author:         Octave
Creator:        GL2PS 1.4.0, (C) 1999-2017 C. Geuzaine
Producer:       GPL Ghostscript 9.26
CreationDate:   Wed Mar 27 22:55:35 2019 CDT
ModDate:        Wed Mar 27 22:55:35 2019 CDT
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      360 x 252 pts
Page rot:       0
File size:      6803 bytes
Optimized:      no
PDF version:    1.7

rm -rf doc/interpreter/extended.pdf
make V=1

pdfinfo doc/interpreter/extended.pdf
Creator:        TeX
Producer:       pdfTeX-1.40.19
CreationDate:   Thu Mar 28 10:18:18 2019 CDT
ModDate:        Thu Mar 28 10:18:18 2019 CDT
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      360 x 252 pts
Page rot:       0
File size:      78740 bytes
Optimized:      no
PDF version:    1.5

(Yes I see pdf warnings now, but again those seems harmless.)

rm -rf doc/interpreter/convhull.pdf
GS_OPTIONS="-dCompatibilityLevel=1.5" make V=1

pdfinfo doc/interpreter/convhull.pdf
Title:          gl2ps_renderer figure
Author:         Octave
Creator:        GL2PS 1.4.0, (C) 1999-2017 C. Geuzaine
Producer:       GPL Ghostscript 9.26
CreationDate:   Thu Mar 28 10:22:02 2019 CDT
ModDate:        Thu Mar 28 10:22:02 2019 CDT
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      360 x 252 pts
Page rot:       0
File size:      6803 bytes
Optimized:      no
PDF version:    1.5

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 28 Mar 2019 03:15:13 PM UTC, comment #14: 

Those two files are produced by pdfTeX.
Any files that touched by ghostscript is pdf 1.7.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Thu 28 Mar 2019 03:00:50 PM UTC, comment #13: 

@Dmitri: It appears that two of your pdf files are version 1.5: extended.pdf and octave.pdf.

You might try removing them and running make to see if they are re-built as 1.7 versions.

@Andrew:

Looking in your log, there appears to be much trouble constructing the pdf files.

I see

/bin/sh run-octave --norc --silent --no-history --path /Users/janke/local/repos/octave-BUILD/build/../../octave/doc/interpreter/ --eval "splineimages ('doc/interpreter/', 'splinefit6', 'pdf');"
warning: opengl_renderer: Error 'invalid framebuffer operation' (1286) occurred in init_gl_context
warning: called from
    __opengl_print__ at line 198 column 7
    print at line 697 column 16
    splineimages at line 166 column 5

And this same error about 'invalid framebuffer operation' is repeated many, many times.

What if you you really, really start over by doing a new hg clone from Octave's repo, and then "autogen.sh; configure; make"

Finally, last option is to let sleeping dogs lie.  If the warning has gone away, great.  Maybe it was just gremlins.

Rik <rik5>
Project Administrator
Thu 28 Mar 2019 02:10:52 AM UTC, comment #12: 

Here it is:

for file in doc/interpreter/*.pdf ; do file $file; done
doc/interpreter/convhull.pdf: PDF document, version 1.7
doc/interpreter/delaunay.pdf: PDF document, version 1.7
doc/interpreter/errorbar.pdf: PDF document, version 1.7
doc/interpreter/extended.pdf: PDF document, version 1.5
doc/interpreter/gplot.pdf: PDF document, version 1.7
doc/interpreter/griddata.pdf: PDF document, version 1.7
doc/interpreter/grid.pdf: PDF document, version 1.7
doc/interpreter/hist.pdf: PDF document, version 1.7
doc/interpreter/inpolygon.pdf: PDF document, version 1.7
doc/interpreter/interpderiv1.pdf: PDF document, version 1.7
doc/interpreter/interpderiv2.pdf: PDF document, version 1.7
doc/interpreter/interpft.pdf: PDF document, version 1.7
doc/interpreter/interpn.pdf: PDF document, version 1.7
doc/interpreter/mesh.pdf: PDF document, version 1.7
doc/interpreter/octave.pdf: PDF document, version 1.5
doc/interpreter/plot3.pdf: PDF document, version 1.7
doc/interpreter/plot.pdf: PDF document, version 1.7
doc/interpreter/polar.pdf: PDF document, version 1.7
doc/interpreter/spchol.pdf: PDF document, version 1.7
doc/interpreter/spcholperm.pdf: PDF document, version 1.7
doc/interpreter/splinefit1.pdf: PDF document, version 1.7
doc/interpreter/splinefit2.pdf: PDF document, version 1.7
doc/interpreter/splinefit3.pdf: PDF document, version 1.7
doc/interpreter/splinefit4.pdf: PDF document, version 1.7
doc/interpreter/splinefit6.pdf: PDF document, version 1.7
doc/interpreter/spmatrix.pdf: PDF document, version 1.7
doc/interpreter/triplot.pdf: PDF document, version 1.7
doc/interpreter/voronoi.pdf: PDF document, version 1.7

Dmitri A. Sergatskov <dasergatskov>
Thu 28 Mar 2019 02:05:09 AM UTC, comment #11: 

FWIW -- all my figures are pdf 1.7 (produced by ghostscript)
but that does not seem to cause any problem.

ghostscript 9.26
pdfTeX 3.14159265-2.6-1.40.19 (TeX Live 2018)

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 28 Mar 2019 01:36:13 AM UTC, comment #10: 

> Can you run with 'make V=1' so that we can see the toolchain that is creating the PDF files?


Here's a full `make V=1` build log file: https://github.com/octave-app/octave-app/files/3015856/build-verbose-for-pdftex-warnings-01.log

Oddly enough, now I don't see the PDF version warnings. I don't recall making any changes to my system aside from regular `brew upgrade`s.

> What version of gl2ps are you using?


$ brew info gl2ps
gl2ps: stable 1.4.0 (bottled)

Also, if you just create a file using Octave, what is the PDF level?

[build] $ ./run-octave --eval 'sombrero; print -dpdf sombrero.pdf; exit'
[build] $ file sombrero.pdf
sombrero.pdf: PDF document, version 1.5
[build] $ pdfinfo sombrero.pdf
Producer:       GPL Ghostscript 9.23
CreationDate:   Wed Mar 27 21:31:20 2019 EDT
ModDate:        Wed Mar 27 21:31:20 2019 EDT
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      612 x 792 pts (letter)
Page rot:       0
File size:      279419 bytes
Optimized:      no
PDF version:    1.5
[build] $

And now my generated splinefit6.pdf is also PDF version 1.5.

$ pdfinfo doc/interpreter/splinefit6.pdf
Producer:       GPL Ghostscript 9.23
CreationDate:   Wed Mar 27 21:18:46 2019 EDT
ModDate:        Wed Mar 27 21:18:46 2019 EDT
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      360 x 252 pts
Page rot:       0
File size:      2843 bytes
Optimized:      no
PDF version:    1.5

And I'm getting octave.pdf.

$ find . -name octave.pdf
./doc/interpreter/octave.pdf

This was done with the latest default code. Maybe something changed in the Octave source?

Andrew Janke <apjanke>
Wed 27 Mar 2019 07:30:51 PM UTC, comment #9: 

@Andrew: Can you run with 'make V=1' so that we can see the toolchain that is creating the PDF files?  You can manually delete doc/interpreter/splinefit6.pdf in order to force it to be re-built.

Rik <rik5>
Project Administrator
Tue 19 Mar 2019 10:03:06 PM UTC, comment #8: 

A quick fix is to set

GS_OPTIONS="-dCompatibilityLevel=1.4"

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 19 Mar 2019 09:48:50 PM UTC, comment #7: 

I am pretty sure it is ghostscript that writes "1.7" ext level into file, though as far as I know it does not use any features past 1.5 (or may be even 1.4). I guess we can sneak in
"-dCompatibilityLevel=1.4" if that helps.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 19 Mar 2019 09:20:42 PM UTC, comment #6: 

@Andrew: What version of gl2ps are you using?  That might be relevant.

Also, if you just create a file using Octave, what is the PDF level?

graphics_toolkit qt
clf
sombrero
print tst.pdf
exit

pdfinfo tst.pdf

I think running make with "V=1" and saving the output would be a good step as Mike suggested so that we can see what actual tools are being run.

Rik <rik5>
Project Administrator
Thu 14 Mar 2019 07:36:31 PM UTC, comment #5: 

I have ghostscript 9.26. I've also now tried building the pdf doc images with gl2ps and with gnuplot (forced with 'env DISPLAY= make all').

With gl2ps 1.4.0:

$ pdfinfo doc/interpreter/splinefit6.pdf
Title:          gl2ps_renderer figure
Author:         Octave
Creator:        GL2PS 1.4.0, (C) 1999-2017 C. Geuzaine
Producer:       GPL Ghostscript 9.26
CreationDate:   Thu Mar 14 11:13:10 2019 PDT
ModDate:        Thu Mar 14 11:13:10 2019 PDT
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      360 x 252 pts
Page rot:       0
File size:      25703 bytes
Optimized:      no
PDF version:    1.7

With gnuplot 5.2.6:

$ pdfinfo doc/interpreter/splinefit6.pdf
Title:          /tmp/oct-DqDWcE.eps
Subject:        gnuplot plot
Creator:        gnuplot 5.2 patchlevel 6
Producer:       GPL Ghostscript 9.26
CreationDate:   Thu Mar 14 12:26:26 2019
ModDate:        Thu Mar 14 12:26:26 2019 PDT
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      360 x 252 pts
Page rot:       0
File size:      22696 bytes
Optimized:      no
PDF version:    1.7

You can do a verbose build with 'make all V=1' and see if /usr/bin/texi show up in the build log.

The error or warning messages that this bug is about, about inclusion of these PDF images, can only occur in the texi2pdf build command for producing octave.pdf. If you're not getting octave.pdf, then that's probably related to this bug.

Octave crashing in bug #55268 is about creating these plot image files. Once the plot images exist, Octave isn't run anymore.

You could try copying the images from the 5.1.0 official release tarball into your build tree, and see if texi2pdf builds octave.pdf successfully.

Mike Miller <mtmiller>
Project Administrator
Thu 14 Mar 2019 06:57:23 PM UTC, comment #4: 

> This is odd. It seems like there is a possible mismatch between the TexInfo tools on your computer and the PDF files generated by gl2ps and ghostscript.


I've got recent TeXLive (MacTeX 2018), Texinfo (6.6), and Ghostscript (9.23) installed on my machine. I think those are the most recent versions of each.

But that Ghostscript-generated PDF file is indeed PDF 1.5 for me, unlike your 1.7 version.

[~/local/repos/octave-BUILD/build/doc/interpreter]
$ pdfinfo splinefit6.pdf
Producer:       GPL Ghostscript 9.23
CreationDate:   Thu Mar 14 14:46:14 2019 EDT
ModDate:        Thu Mar 14 14:46:14 2019 EDT
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      360 x 252 pts
Page rot:       0
File size:      2843 bytes
Optimized:      no
PDF version:    1.5
[~/local/repos/octave-BUILD/build/doc/interpreter]
$ texi2pdf --version
texi2pdf (GNU Texinfo 6.6)

Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
[~/local/repos/octave-BUILD/build/doc/interpreter]
$ which texi2pdf
/usr/local/opt/texinfo/bin/texi2pdf
[~/local/repos/octave-BUILD/build/doc/interpreter]
$ pdfetex --version
pdfTeX 3.14159265-2.6-1.40.19 (TeX Live 2018)
kpathsea version 6.3.0
Copyright 2018 Han The Thanh (pdfTeX) et al.
There is NO warranty.  Redistribution of this software is
covered by the terms of both the pdfTeX copyright and
the Lesser GNU General Public License.
For more information about these matters, see the file
named COPYING and the pdfTeX source.
Primary author of pdfTeX: Han The Thanh (pdfTeX) et al.
Compiled with libpng 1.6.34; using libpng 1.6.34
Compiled with zlib 1.2.11; using zlib 1.2.11
Compiled with xpdf version 4.00
[~/local/repos/octave-BUILD/build/doc/interpreter]
$ which pdfetex
/Library/TeX/texbin/pdfetex
[~/local/repos/octave-BUILD/build/doc/interpreter]
$ gs --version
9.23

The Mac situation is a little weird: macOS ships with an ancient (4.8) version of Texinfo. So I have an additional Homebrewed installation of the new 6.6 Texinfo in /usr/local/opt. I have my $PATH set up to pull in the new Texinfo (confirmed by `which` in output above). I wonder if maybe some tool here is ignoring the path and calling /usr/bin/texi* tools directly?

Andrew Janke <apjanke>
Thu 14 Mar 2019 06:50:09 PM UTC, comment #3: 

>  look at doc/interpreter/octave.pdf


I don't even have an octave.pdf file there. I think this is due to bug #55268 (octave crashes during doc generation stage of build on macOS).

Andrew Janke <apjanke>
Thu 14 Mar 2019 06:03:22 PM UTC, comment #2: 

I also don't see these warnings, I have pdfTeX 3.14159265-2.6-1.40.19 (TeX Live 2019/dev/Debian).

@apjanke If you want to see whether the result looks good despite the warnings, look at doc/interpreter/octave.pdf. The simplest plot image is in section 15.2.1, Figure 15.1: Simple Two-Dimensional Plot, which is page 296 in my octave.pdf. If you don't see the image, or just see an empty axes, then something's not right.

Mike Miller <mtmiller>
Project Administrator
Thu 14 Mar 2019 03:24:44 PM UTC, comment #1: 

This is odd.  It seems like there is a possible mismatch between the TexInfo tools on your computer and the PDF files generated by gl2ps and ghostscript.

Taking the first example form your logfile: splinefit6.pdf.

This is created by Octave itself by the code in doc/interpreter/splineimages.m.  If I run pdfinf on the file on my Linux machine I get:

pdfinfo splinefit6.pdf

Title:          gl2ps_renderer figure
Author:         Octave
Creator:        GL2PS 1.4.0, (C) 1999-2017 C. Geuzaine
Producer:       GPL Ghostscript 9.26
CreationDate:   Sun Mar  3 20:47:27 2019 PST
ModDate:        Sun Mar  3 20:47:27 2019 PST
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      360 x 252 pts
Page rot:       0
File size:      25697 bytes
Optimized:      no
PDF version:    1.7

So, it is true that the PDF version is 1.7.

The inclusion into the output is in poly.txi

@float Figure,fig:splinefit6
@center @image{splinefit6,4in}
@caption{Comparison of two different levels of robust fitting (@var{beta} = 0.25 and 0.75) to noisy data combined with outlying data.  A conventional fit, without
robust fitting (@var{beta} = 0) is also included.}
@end float

The .txi is munged to form a .texi file (Texinfo format) and later made a pdf file with pdfetex.  Versions on my computer are

texinfo         6.5.0.dfsg.1
texlive-binaries 2017.2017061  (for pdfetex)

Maybe your texlive installation is too old?

Rik <rik5>
Project Administrator
Thu 14 Mar 2019 09:37:10 AM UTC, original submission:  

When building default, I'm getting lots of warnings about a too-new version of an included PDF.

Example:

pdfTeX warning: pdfetex (file /private/tmp/octave-default-20190314-85390-suxuro
/doc/interpreter/splinefit6.pdf): PDF inclusion: found PDF version <1.7>, but a
t most version <1.5> allowed
</private/tmp/octave-default-20190314-85390-suxuro/doc/interpreter/splinefit6.
pdf> [786] [787] [788])
(/private/tmp/octave-default-20190314-85390-suxuro/doc/interpreter/interp.texi
Chapter 29 [789] [790] [791]

pdfTeX warning: pdfetex (file /private/tmp/octave-default-20190314-85390-suxuro
/doc/interpreter/interpderiv1.pdf): PDF inclusion: found PDF version <1.7>, but
at most version <1.5> allowed
</private/tmp/octave-default-20190314-85390-suxuro/doc/interpreter/interpderiv
1.pdf> [792]

pdfTeX warning: pdfetex (file /private/tmp/octave-default-20190314-85390-suxuro
/doc/interpreter/interpderiv2.pdf): PDF inclusion: found PDF version <1.7>, but
at most version <1.5> allowed
</private/tmp/octave-default-20190314-85390-suxuro/doc/interpreter/interpderiv
2.pdf> [793]

pdfTeX warning: pdfetex (file /private/tmp/octave-default-20190314-85390-suxuro
/doc/interpreter/interpft.pdf): PDF inclusion: found PDF version <1.7>, but at
most version <1.5> allowed
</private/tmp/octave-default-20190314-85390-suxuro/doc/interpreter/interpft.pd
f> [794] [795] [796] [797]

Full build logs: https://gist.github.com/0abf93cef8ac9caf7ca80f7db6008e1

I can't tell where these PDFs are ending up in the final generated documentation, so I can't tell if something is actually going wrong. I examined the doc/interpreter/*.pdf files in the build directory, and most of them look like plots that are missing the actual plot graphics (only axes labels are visible), but I don't know if that's expected.

Andrew Janke <apjanke>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by apjanke (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-29 rik5 Open/ClosedOpen => Closed

    Back to the top


    Powered by Savane 3.5