* Re: Data on PDF vs PS (Was Re: Online docs page should ..) [With prelim patch]
@ 1999-12-21 3:22 Jan Vroonhof
1999-12-22 10:15 ` Marc Lehmann
1999-12-31 23:54 ` Jan Vroonhof
0 siblings, 2 replies; 10+ messages in thread
From: Jan Vroonhof @ 1999-12-21 3:22 UTC (permalink / raw)
To: Marc Lehmann; +Cc: gcc
[I should have said I am not subscribed to the list. I read from the
archives only. Please CC in direct discussion]
I had intended to not turn this into discussion, but one of your
points below is IMHO is wrong.
> > 1. PDF files [produced with free software] are large and low quality.
>
> At least this point is proven with your data (so there is not really a
> lakc of knowledge in this point ;). both gzipped und plain pdf files are
> larger than gzipped ps files.
Yes, but the gzipped pdf files are only about 10% larger.
> But only when not gzipped. Which means that pdf files are about
> twice as large as corresponding postscript files. Both are not
> browsable online.
That is wrong. Have you tried the link in my messages? My browser
unzips it just fine before sending it to the PDF viewers.
> But actually, I doubt that a pdf version will be more sueful than a html
> version (that already exists).
Does the html version exist in a bundle for download? (if so it isn't
linked to from the website).
Personally I find the PDF version much more comfortable to read on
screen that the HTML version. In large documents, good typersetting
becomes important In addition the PDF version is much more favorable
to the "go online,fetch docs,go ofline,read" style of reading (and
that is probably easier on the server too).
Anyway, you decide what to do. If you want I can complete the "make
pdf" match at some later point.
Jan
P.S. As I more or less live in Emacs for me a precompiled set of info
files on the website would be the preferred option, but I would take
PDF over both HTML and PS.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Data on PDF vs PS (Was Re: Online docs page should ..) [With prelim patch]
1999-12-21 3:22 Data on PDF vs PS (Was Re: Online docs page should ..) [With prelim patch] Jan Vroonhof
@ 1999-12-22 10:15 ` Marc Lehmann
1999-12-22 15:36 ` Geoff Keating
1999-12-31 23:54 ` Marc Lehmann
1999-12-31 23:54 ` Jan Vroonhof
1 sibling, 2 replies; 10+ messages in thread
From: Marc Lehmann @ 1999-12-22 10:15 UTC (permalink / raw)
To: Jan Vroonhof; +Cc: Marc Lehmann, gcc
On Tue, Dec 21, 1999 at 12:22:12PM +0100, Jan Vroonhof <vroonhof@math.ethz.ch> wrote:
> > At least this point is proven with your data (so there is not really a
> > lakc of knowledge in this point ;). both gzipped und plain pdf files are
> > larger than gzipped ps files.
>
> Yes, but the gzipped pdf files are only about 10% larger.
Ok. I still fail to see the added benefit of first compressing with lzw
(pdf) and then with gzip, and then still having larger files ;)
> That is wrong. Have you tried the link in my messages?
No, I answer 99% of my mail offline, so I am dependent on the content in
mails ;(
> My browser unzips it just fine before sending it to the PDF viewers.
OK.
> Does the html version exist in a bundle for download? (if so it isn't
> linked to from the website).
Hmm... "if it isn't linked it doesn't exist.."
So, since having too many versions is better than too little, I would now
want both .ps.gz and .pdf.gz versions of the documents (ps files are still
easier to print on most machines), if we want to have these downloadable
at all.
> Anyway, you decide what to do.
I don't decide. I am not even sure who "decides" ;) The problem is two-fold:
a) one has to find somebody who will do the actual works (the manuals
should be kept up-to-date)
b) the admin of gcc.gnu.org has not yet said anything, but I guess neither
the bandwidth nor the load are a problem.
OTOH, this might be a micro-optimization anyway, as it is possible to create
postscript docs form the sources, and maybe soon pdf as well.
> If you want I can complete the "make pdf" match at some later point.
I think that would be nice. Ultimately someone else has to decide wether this
patch goes in, but I don't see a problem here (as it would be nice to have).
> P.S. As I more or less live in Emacs for me a precompiled set of info
> files on the website would be the preferred option, but I would take PDF
> over both HTML and PS.
The question is wether it isn't easier to just 'make pdf' or 'make info'?
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@opengroup.org |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Data on PDF vs PS (Was Re: Online docs page should ..) [With prelim patch]
1999-12-22 10:15 ` Marc Lehmann
@ 1999-12-22 15:36 ` Geoff Keating
1999-12-31 23:54 ` Geoff Keating
1999-12-31 23:54 ` Marc Lehmann
1 sibling, 1 reply; 10+ messages in thread
From: Geoff Keating @ 1999-12-22 15:36 UTC (permalink / raw)
To: Marc Lehmann; +Cc: gcc
Marc Lehmann <pcg@opengroup.org> writes:
> On Tue, Dec 21, 1999 at 12:22:12PM +0100, Jan Vroonhof <vroonhof@math.ethz.ch> wrote:
> > > At least this point is proven with your data (so there is not really a
> > > lakc of knowledge in this point ;). both gzipped und plain pdf files are
> > > larger than gzipped ps files.
> >
> > Yes, but the gzipped pdf files are only about 10% larger.
>
> Ok. I still fail to see the added benefit of first compressing with lzw
> (pdf) and then with gzip, and then still having larger files ;)
PDF files generated with free software, or with modern versions of the
Adobe tools, invariably use gzip compression internally too.
The reason they still shrink when you gzip them again is that
the metadata is in plain-text to support incremental downloading and
viewing single pages without having to decompress the whole thing.
> > My browser unzips it just fine before sending it to the PDF viewers.
The disadvantage of compressing the whole file is that then your
browser must download the whole file before showing you the first page.
If you don't compress it, have a newer HTTP server, and have the right
plug-in for your browser, it can download a page at a time and show
you the first page as soon as it gets it.
--
- Geoffrey Keating <geoffk@cygnus.com>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Data on PDF vs PS (Was Re: Online docs page should ..) [With prelim patch]
1999-12-21 3:22 Data on PDF vs PS (Was Re: Online docs page should ..) [With prelim patch] Jan Vroonhof
1999-12-22 10:15 ` Marc Lehmann
@ 1999-12-31 23:54 ` Jan Vroonhof
1 sibling, 0 replies; 10+ messages in thread
From: Jan Vroonhof @ 1999-12-31 23:54 UTC (permalink / raw)
To: Marc Lehmann; +Cc: gcc
[I should have said I am not subscribed to the list. I read from the
archives only. Please CC in direct discussion]
I had intended to not turn this into discussion, but one of your
points below is IMHO is wrong.
> > 1. PDF files [produced with free software] are large and low quality.
>
> At least this point is proven with your data (so there is not really a
> lakc of knowledge in this point ;). both gzipped und plain pdf files are
> larger than gzipped ps files.
Yes, but the gzipped pdf files are only about 10% larger.
> But only when not gzipped. Which means that pdf files are about
> twice as large as corresponding postscript files. Both are not
> browsable online.
That is wrong. Have you tried the link in my messages? My browser
unzips it just fine before sending it to the PDF viewers.
> But actually, I doubt that a pdf version will be more sueful than a html
> version (that already exists).
Does the html version exist in a bundle for download? (if so it isn't
linked to from the website).
Personally I find the PDF version much more comfortable to read on
screen that the HTML version. In large documents, good typersetting
becomes important In addition the PDF version is much more favorable
to the "go online,fetch docs,go ofline,read" style of reading (and
that is probably easier on the server too).
Anyway, you decide what to do. If you want I can complete the "make
pdf" match at some later point.
Jan
P.S. As I more or less live in Emacs for me a precompiled set of info
files on the website would be the preferred option, but I would take
PDF over both HTML and PS.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Data on PDF vs PS (Was Re: Online docs page should ..) [With prelim patch]
1999-12-22 15:36 ` Geoff Keating
@ 1999-12-31 23:54 ` Geoff Keating
0 siblings, 0 replies; 10+ messages in thread
From: Geoff Keating @ 1999-12-31 23:54 UTC (permalink / raw)
To: Marc Lehmann; +Cc: gcc
Marc Lehmann <pcg@opengroup.org> writes:
> On Tue, Dec 21, 1999 at 12:22:12PM +0100, Jan Vroonhof <vroonhof@math.ethz.ch> wrote:
> > > At least this point is proven with your data (so there is not really a
> > > lakc of knowledge in this point ;). both gzipped und plain pdf files are
> > > larger than gzipped ps files.
> >
> > Yes, but the gzipped pdf files are only about 10% larger.
>
> Ok. I still fail to see the added benefit of first compressing with lzw
> (pdf) and then with gzip, and then still having larger files ;)
PDF files generated with free software, or with modern versions of the
Adobe tools, invariably use gzip compression internally too.
The reason they still shrink when you gzip them again is that
the metadata is in plain-text to support incremental downloading and
viewing single pages without having to decompress the whole thing.
> > My browser unzips it just fine before sending it to the PDF viewers.
The disadvantage of compressing the whole file is that then your
browser must download the whole file before showing you the first page.
If you don't compress it, have a newer HTTP server, and have the right
plug-in for your browser, it can download a page at a time and show
you the first page as soon as it gets it.
--
- Geoffrey Keating <geoffk@cygnus.com>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Data on PDF vs PS (Was Re: Online docs page should ..) [With prelim patch]
1999-12-22 10:15 ` Marc Lehmann
1999-12-22 15:36 ` Geoff Keating
@ 1999-12-31 23:54 ` Marc Lehmann
1 sibling, 0 replies; 10+ messages in thread
From: Marc Lehmann @ 1999-12-31 23:54 UTC (permalink / raw)
To: Jan Vroonhof; +Cc: Marc Lehmann, gcc
On Tue, Dec 21, 1999 at 12:22:12PM +0100, Jan Vroonhof <vroonhof@math.ethz.ch> wrote:
> > At least this point is proven with your data (so there is not really a
> > lakc of knowledge in this point ;). both gzipped und plain pdf files are
> > larger than gzipped ps files.
>
> Yes, but the gzipped pdf files are only about 10% larger.
Ok. I still fail to see the added benefit of first compressing with lzw
(pdf) and then with gzip, and then still having larger files ;)
> That is wrong. Have you tried the link in my messages?
No, I answer 99% of my mail offline, so I am dependent on the content in
mails ;(
> My browser unzips it just fine before sending it to the PDF viewers.
OK.
> Does the html version exist in a bundle for download? (if so it isn't
> linked to from the website).
Hmm... "if it isn't linked it doesn't exist.."
So, since having too many versions is better than too little, I would now
want both .ps.gz and .pdf.gz versions of the documents (ps files are still
easier to print on most machines), if we want to have these downloadable
at all.
> Anyway, you decide what to do.
I don't decide. I am not even sure who "decides" ;) The problem is two-fold:
a) one has to find somebody who will do the actual works (the manuals
should be kept up-to-date)
b) the admin of gcc.gnu.org has not yet said anything, but I guess neither
the bandwidth nor the load are a problem.
OTOH, this might be a micro-optimization anyway, as it is possible to create
postscript docs form the sources, and maybe soon pdf as well.
> If you want I can complete the "make pdf" match at some later point.
I think that would be nice. Ultimately someone else has to decide wether this
patch goes in, but I don't see a problem here (as it would be nice to have).
> P.S. As I more or less live in Emacs for me a precompiled set of info
> files on the website would be the preferred option, but I would take PDF
> over both HTML and PS.
The question is wether it isn't easier to just 'make pdf' or 'make info'?
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@opengroup.org |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Data on PDF vs PS (Was Re: Online docs page should ..) [With prelim patch]
1999-12-20 13:55 ` Marc Lehmann
@ 1999-12-31 23:54 ` Marc Lehmann
0 siblings, 0 replies; 10+ messages in thread
From: Marc Lehmann @ 1999-12-31 23:54 UTC (permalink / raw)
To: gcc
On Mon, Dec 20, 1999 at 09:56:58PM +0100, Jan Vroonhof <vroonhof@math.ethz.ch> wrote:
> discussion about including PDF files on the web site. It seems to me
> there was a lack of knowledge of the state of the art of producing PDF
> files with free software [apologies if I am misreading those messages]
>
> 1. PDF files [produced with free software] are large and low quality.
At least this point is proven with your data (so there is not really a
lakc of knowledge in this point ;). both gzipped und plain pdf files are
larger than gzipped ps files.
> Both file types are fully scalable. In my experience PDF files
> are easier to deal with on non-unix platforms.
But only when not gzipped. Which means that pdf files are about twice as
large as corresponding postscript files. Both are not browsable online.
That means, that if we want to reduce the transfer load on the servers pdf is
the wrong choice.
If we weant to provide .pdf files for platforms incapable of ps+html
processing, we could eat 2x the data to help these.
But actually, I doubt that a pdf version will be more sueful than a html
version (that already exists).
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@opengroup.org |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
^ permalink raw reply [flat|nested] 10+ messages in thread
* Data on PDF vs PS (Was Re: Online docs page should ..) [With prelim patch]
1999-12-20 12:57 Jan Vroonhof
1999-12-20 13:55 ` Marc Lehmann
@ 1999-12-31 23:54 ` Jan Vroonhof
1 sibling, 0 replies; 10+ messages in thread
From: Jan Vroonhof @ 1999-12-31 23:54 UTC (permalink / raw)
To: gcc
[Example at http://www.math.ethz.ch/~vroonhof/gcc.pdf.gz ]
I was browsing the archives of this list and happen to hit on the
discussion about including PDF files on the web site. It seems to me
there was a lack of knowledge of the state of the art of producing PDF
files with free software [apologies if I am misreading those messages]
In particular
1. PDF files [produced with free software] are large and low quality.
2. PDF files [ ..] currently do not offer hyperlinks so are of no
extra value.
3. Producing those PDF files is somehow difficult.
In my opinion these are misconceptions, so I hope the data provided in
this message will clear some stuff up. Feel free to do with it what
you like. A preliminary patch for a "make pdf" target is included at
the end.
Ad 1. Unless you run a current Ghostscript beta, it indeed produces
bloated PDF files. However, for processing texinfo, it is the wrong
tool for the job.
Using pdftex + texinfo.tex from texinfo 4.0 gives (this is the "make
pdf" target in the patch below.)
gcc.pdf 2201833 bytes
gcc.pdf.gz 1497979 bytes
(without hyperlinks gcc.pdf.gz gives about 1380000 bytes)
make dvi + dvips -Pwww (includes scalable fonts)
gcc.ps 3374213 bytes
gcc.ps.gz 1237542 bytes
Both file types are fully scalable. In my experience PDF files
are easier to deal with on non-unix platforms.
Ad 2. With Texinfo 4.0, the pdf files are fully linked, see
http://www.math.ethz.ch/~vroonhof/gcc.pdf.gz
for an example.
Ad 3. On a modern TeX installation (i.e. teTeX 1.0) producing PDF
instead of dvi is a matter of running pdftex instead of normal tex.
Below is an only partially tested patch that provides "make pdf"
support for the core gcc. It could probably be improved by reducing
the code duplication between the dvi and tex cases.
Such a patch would be useful regardless of what gets put on the
website.
diff -ur gcc-2.95.2.old/Makefile.in gcc-2.95.2/Makefile.in
--- gcc-2.95.2.old/Makefile.in Wed Jun 23 00:44:42 1999
+++ gcc-2.95.2/Makefile.in Mon Dec 20 20:18:20 1999
@@ -961,6 +961,7 @@
do-clean \
do-distclean \
do-dvi \
+ do-pdf \
do-info \
do-install-info \
do-installcheck \
@@ -1019,12 +1020,13 @@
# Here are the targets which correspond to the do-X targets.
-.PHONY: info installcheck dvi install-info
+.PHONY: info installcheck dvi pdf install-info
.PHONY: clean distclean mostlyclean maintainer-clean realclean
.PHONY: local-clean local-distclean local-maintainer-clean
info: do-info
installcheck: do-installcheck
dvi: do-dvi
+pdf: do-pdf
# Make sure makeinfo is built before we do a `make info'.
do-info: all-texinfo
diff -ur gcc-2.95.2.old/etc/Makefile.in gcc-2.95.2/etc/Makefile.in
--- gcc-2.95.2.old/etc/Makefile.in Sat May 16 01:52:29 1998
+++ gcc-2.95.2/etc/Makefile.in Mon Dec 20 20:23:25 1999
@@ -33,6 +33,7 @@
MAKEINFO = makeinfo
TEXI2DVI = texi2dvi
+TEXI2PDF = texi2pdf
# Where to find texinfo.tex to format documentation with TeX.
TEXIDIR = $(srcdir)/../texinfo
@@ -42,6 +43,7 @@
INFOFILES = standards.info
DVIFILES = standards.dvi
+PDFFILES = standards.pdf
all:
@@ -59,15 +61,19 @@
dvi: $(DVIFILES)
+pdf: $(PDFFILES)
+
standards.info: $(srcdir)/standards.texi $(srcdir)/make-stds.texi
$(MAKEINFO) --no-split -I$(srcdir) -o standards.info $(srcdir)/standards.texi
standards.dvi: $(srcdir)/standards.texi
TEXINPUTS=$(TEXIDIR):$$TEXINPUTS $(TEXI2DVI) $(srcdir)/standards.texi
+standards.pdf: $(srcdir)/standards.texi
+ TEXINPUTS=$(TEXIDIR):$$TEXINPUTS $(TEXI2PDF) $(srcdir)/standards.texi
clean:
- rm -f *.aux *.cp *.cps *.dvi *.fn *.fns *.ky *.kys *.log
+ rm -f *.aux *.cp *.cps *.dvi *.pdf *.fn *.fns *.ky *.kys *.log
rm -f *.pg *.pgs *.toc *.tp *.tps *.vr *.vrs
mostlyclean: clean
diff -ur gcc-2.95.2.old/gcc/Makefile.in gcc-2.95.2/gcc/Makefile.in
--- gcc-2.95.2.old/gcc/Makefile.in Fri Aug 13 09:46:55 1999
+++ gcc-2.95.2/gcc/Makefile.in Mon Dec 20 20:03:21 1999
@@ -2290,6 +2290,20 @@
texindex cpp.??
TEXINPUTS=${texidir}:$(srcdir):$$TEXINPUTS tex cpp.texi
+pdf: gcc.pdf cpp.pdf lang.pdf
+
+gcc.pdf: $(srcdir)/gcc.texi $(srcdir)/extend.texi $(srcdir)/install.texi \
+ $(srcdir)/invoke.texi $(srcdir)/md.texi $(srcdir)/rtl.texi \
+ $(srcdir)/tm.texi $(srcdir)/gcov.texi
+ TEXINPUTS=${texidir}:$(srcdir):$$TEXINPUTS pdftex gcc.texi
+ texindex gcc.??
+ TEXINPUTS=${texidir}:$(srcdir):$$TEXINPUTS pdftex gcc.texi
+
+cpp.pdf: $(srcdir)/cpp.texi
+ TEXINPUTS=${texidir}:$(srcdir):$$TEXINPUTS pdftex cpp.texi
+ texindex cpp.??
+ TEXINPUTS=${texidir}:$(srcdir):$$TEXINPUTS pdftex cpp.texi
+
INSTALL: $(srcdir)/install1.texi $(srcdir)/install.texi
cd $(srcdir); $(MAKEINFO) -D INSTALLONLY \
diff -ur gcc-2.95.2.old/gcc/ch/Make-lang.in gcc-2.95.2/gcc/ch/Make-lang.in
--- gcc-2.95.2.old/gcc/ch/Make-lang.in Fri Jun 25 10:26:19 1999
+++ gcc-2.95.2/gcc/ch/Make-lang.in Mon Dec 20 20:44:27 1999
@@ -106,6 +106,7 @@
CHILL.start.encap: chill
CHILL.rest.encap:
CHILL.dvi: chill.dvi
+CHILL.pdf: chill.pdf
CHILL.info: ch/chill.info
@@ -119,6 +120,14 @@
TEXINPUTS=${texidir}:$(srcdir):$$TEXINPUTS tex chill.texi
# FIXME: Not sure languages should do this.
cp ch/chill.dvi chill.dvi
+
+chill.pdf: $(srcdir)/ch/chill.texi $(srcdir)/extend.texi $(srcdir)/invoke.texi $(srcdir)/md.texi $(srcdir)/rtl.texi $(srcdir)/tm.texi
+ cd ch ; \
+ TEXINPUTS=${texidir}:$(srcdir):$$TEXINPUTS pdftex chill.texi ; \
+ texindex chill.?? ; \
+ TEXINPUTS=${texidir}:$(srcdir):$$TEXINPUTS pdftex chill.texi
+# FIXME: Not sure languages should do this.
+ cp ch/chill.pdf chill.pdf
#\f
# Install hooks:
# cc1chill is installed elsewhere as part of $(COMPILERS).
@@ -168,7 +177,7 @@
CHILL.extraclean:
CHILL.maintainer-clean:
-rm -f ch/TAGS
- -rm -f ch/chill.info* ch/chill.dvi ch/chill.??s ch/chill.*aux
+ -rm -f ch/chill.info* ch/chill.dvi ch/chill.pdf ch/chill.??s ch/chill.*aux
# CYGNUS LOCAL: Delete locally created file.
-rm -f ch/hash.h
#\f
diff -ur gcc-2.95.2.old/gcc/ch/Makefile.in gcc-2.95.2/gcc/ch/Makefile.in
--- gcc-2.95.2.old/gcc/ch/Makefile.in Wed Mar 31 09:47:58 1999
+++ gcc-2.95.2/gcc/ch/Makefile.in Mon Dec 20 20:44:59 1999
@@ -61,6 +61,7 @@
SHELL = /bin/sh
MAKEINFO = makeinfo
TEXI2DVI = texi2dvi
+TEXI2PDF = texi2pdf
# Define this as & to perform parallel make on a Sequent.
# Note that this has some bugs, and it seems currently necessary
diff -ur gcc-2.95.2.old/gcc/configure.in gcc-2.95.2/gcc/configure.in
--- gcc-2.95.2.old/gcc/configure.in Wed Oct 13 09:58:02 1999
+++ gcc-2.95.2/gcc/configure.in Mon Dec 20 20:45:38 1999
@@ -4226,7 +4226,7 @@
rm -f Make-hooks
touch Make-hooks
target_list="all.build all.cross start.encap rest.encap \
- info dvi \
+ info dvi pdf \
install-normal install-common install-info install-man \
uninstall distdir \
mostlyclean clean distclean extraclean maintainer-clean \
diff -ur gcc-2.95.2.old/gcc/cp/Make-lang.in gcc-2.95.2/gcc/cp/Make-lang.in
--- gcc-2.95.2.old/gcc/cp/Make-lang.in Tue Apr 27 01:50:36 1999
+++ gcc-2.95.2/gcc/cp/Make-lang.in Mon Dec 20 20:31:09 1999
@@ -132,6 +132,7 @@
c++.info:
c++.dvi:
+c++.pdf:
# C++ language-support library pieces for libgcc.
tinfo.o: cc1plus$(exeext) $(srcdir)/cp/tinfo.cc
diff -ur gcc-2.95.2.old/gcc/cp/Makefile.in gcc-2.95.2/gcc/cp/Makefile.in
--- gcc-2.95.2.old/gcc/cp/Makefile.in Sun Jul 25 23:27:38 1999
+++ gcc-2.95.2/gcc/cp/Makefile.in Mon Dec 20 20:31:31 1999
@@ -68,6 +68,7 @@
SHELL = /bin/sh
MAKEINFO = makeinfo
TEXI2DVI = texi2dvi
+TEXI2PDF = texi2pdf
# Define this as & to perform parallel make on a Sequent.
# Note that this has some bugs, and it seems currently necessary
diff -ur gcc-2.95.2.old/gcc/f/Make-lang.in gcc-2.95.2/gcc/f/Make-lang.in
--- gcc-2.95.2.old/gcc/f/Make-lang.in Mon Jun 7 08:44:57 1999
+++ gcc-2.95.2/gcc/f/Make-lang.in Mon Dec 20 20:48:33 1999
@@ -52,7 +52,7 @@
# Tell GNU make to ignore these if they exist.
.PHONY: F77 f77 f77.all.build f77.all.cross \
- f77.start.encap f77.rest.encap f77.info f77.dvi \
+ f77.start.encap f77.rest.encap f77.info f77.dvi f77.pdf\
f77.install-normal \
f77.install-common f77.install-info f77.install-man \
f77.uninstall f77.mostlyclean f77.clean f77.distclean \
@@ -250,6 +250,26 @@
TEXINPUTS=$(srcdir)/f:$$TEXINPUTS tex $(srcdir)/f/g77.texi; \
mv g77.dvi f; \
else true; fi
+
+f/g77.pdf: $(srcdir)/f/g77.texi $(srcdir)/f/bugs.texi \
+ $(srcdir)/f/ffe.texi \
+ $(srcdir)/f/g77install.texi $(srcdir)/f/news.texi \
+ $(srcdir)/f/intdoc.texi $(srcdir)/f/root.texi
+ case "$(LANGUAGES)" in \
+ *[fF]77*) touch lang-f77;; \
+ *) rm -f lang-f77;; \
+ esac
+# `tex2dvi' was used below, but the Texinfo 3.12 one won't work properly
+# with the include files from $(srcdir). This use of TEXINPUTS may not
+# be universally valid. `$(TEX)' should be used if it gets defined in
+# gcc/Makefile.in.
+ if [ -f lang-f77 ]; then \
+ TEXINPUTS=$(srcdir)/f:$$TEXINPUTS pdftex $(srcdir)/f/g77.texi; \
+ texindex g77.??; \
+ TEXINPUTS=$(srcdir)/f:$$TEXINPUTS pdftex $(srcdir)/f/g77.texi; \
+ mv g77.dvi f; \
+ else true; fi
+
# This dance is all about producing accurate documentation for g77's
# intrinsics with minimum fuss. f/ansify appends "\n\" to C strings
diff -ur gcc-2.95.2.old/gcc/f/Makefile.in gcc-2.95.2/gcc/f/Makefile.in
--- gcc-2.95.2.old/gcc/f/Makefile.in Wed Dec 16 22:16:32 1998
+++ gcc-2.95.2/gcc/f/Makefile.in Mon Dec 20 20:46:32 1999
@@ -64,6 +64,7 @@
SHELL = /bin/sh
MAKEINFO = makeinfo
TEXI2DVI = texi2dvi
+TEXI2DVI = texi2pdf
# Define this as & to perform parallel make on a Sequent.
# Note that this has some bugs, and it seems currently necessary
Only in gcc-2.95.2/gcc/intl: #Makefile.in#
Only in gcc-2.95.2: pdfs
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Data on PDF vs PS (Was Re: Online docs page should ..) [With prelim patch]
1999-12-20 12:57 Jan Vroonhof
@ 1999-12-20 13:55 ` Marc Lehmann
1999-12-31 23:54 ` Marc Lehmann
1999-12-31 23:54 ` Jan Vroonhof
1 sibling, 1 reply; 10+ messages in thread
From: Marc Lehmann @ 1999-12-20 13:55 UTC (permalink / raw)
To: gcc
On Mon, Dec 20, 1999 at 09:56:58PM +0100, Jan Vroonhof <vroonhof@math.ethz.ch> wrote:
> discussion about including PDF files on the web site. It seems to me
> there was a lack of knowledge of the state of the art of producing PDF
> files with free software [apologies if I am misreading those messages]
>
> 1. PDF files [produced with free software] are large and low quality.
At least this point is proven with your data (so there is not really a
lakc of knowledge in this point ;). both gzipped und plain pdf files are
larger than gzipped ps files.
> Both file types are fully scalable. In my experience PDF files
> are easier to deal with on non-unix platforms.
But only when not gzipped. Which means that pdf files are about twice as
large as corresponding postscript files. Both are not browsable online.
That means, that if we want to reduce the transfer load on the servers pdf is
the wrong choice.
If we weant to provide .pdf files for platforms incapable of ps+html
processing, we could eat 2x the data to help these.
But actually, I doubt that a pdf version will be more sueful than a html
version (that already exists).
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@opengroup.org |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
^ permalink raw reply [flat|nested] 10+ messages in thread
* Data on PDF vs PS (Was Re: Online docs page should ..) [With prelim patch]
@ 1999-12-20 12:57 Jan Vroonhof
1999-12-20 13:55 ` Marc Lehmann
1999-12-31 23:54 ` Jan Vroonhof
0 siblings, 2 replies; 10+ messages in thread
From: Jan Vroonhof @ 1999-12-20 12:57 UTC (permalink / raw)
To: gcc
[Example at http://www.math.ethz.ch/~vroonhof/gcc.pdf.gz ]
I was browsing the archives of this list and happen to hit on the
discussion about including PDF files on the web site. It seems to me
there was a lack of knowledge of the state of the art of producing PDF
files with free software [apologies if I am misreading those messages]
In particular
1. PDF files [produced with free software] are large and low quality.
2. PDF files [ ..] currently do not offer hyperlinks so are of no
extra value.
3. Producing those PDF files is somehow difficult.
In my opinion these are misconceptions, so I hope the data provided in
this message will clear some stuff up. Feel free to do with it what
you like. A preliminary patch for a "make pdf" target is included at
the end.
Ad 1. Unless you run a current Ghostscript beta, it indeed produces
bloated PDF files. However, for processing texinfo, it is the wrong
tool for the job.
Using pdftex + texinfo.tex from texinfo 4.0 gives (this is the "make
pdf" target in the patch below.)
gcc.pdf 2201833 bytes
gcc.pdf.gz 1497979 bytes
(without hyperlinks gcc.pdf.gz gives about 1380000 bytes)
make dvi + dvips -Pwww (includes scalable fonts)
gcc.ps 3374213 bytes
gcc.ps.gz 1237542 bytes
Both file types are fully scalable. In my experience PDF files
are easier to deal with on non-unix platforms.
Ad 2. With Texinfo 4.0, the pdf files are fully linked, see
http://www.math.ethz.ch/~vroonhof/gcc.pdf.gz
for an example.
Ad 3. On a modern TeX installation (i.e. teTeX 1.0) producing PDF
instead of dvi is a matter of running pdftex instead of normal tex.
Below is an only partially tested patch that provides "make pdf"
support for the core gcc. It could probably be improved by reducing
the code duplication between the dvi and tex cases.
Such a patch would be useful regardless of what gets put on the
website.
diff -ur gcc-2.95.2.old/Makefile.in gcc-2.95.2/Makefile.in
--- gcc-2.95.2.old/Makefile.in Wed Jun 23 00:44:42 1999
+++ gcc-2.95.2/Makefile.in Mon Dec 20 20:18:20 1999
@@ -961,6 +961,7 @@
do-clean \
do-distclean \
do-dvi \
+ do-pdf \
do-info \
do-install-info \
do-installcheck \
@@ -1019,12 +1020,13 @@
# Here are the targets which correspond to the do-X targets.
-.PHONY: info installcheck dvi install-info
+.PHONY: info installcheck dvi pdf install-info
.PHONY: clean distclean mostlyclean maintainer-clean realclean
.PHONY: local-clean local-distclean local-maintainer-clean
info: do-info
installcheck: do-installcheck
dvi: do-dvi
+pdf: do-pdf
# Make sure makeinfo is built before we do a `make info'.
do-info: all-texinfo
diff -ur gcc-2.95.2.old/etc/Makefile.in gcc-2.95.2/etc/Makefile.in
--- gcc-2.95.2.old/etc/Makefile.in Sat May 16 01:52:29 1998
+++ gcc-2.95.2/etc/Makefile.in Mon Dec 20 20:23:25 1999
@@ -33,6 +33,7 @@
MAKEINFO = makeinfo
TEXI2DVI = texi2dvi
+TEXI2PDF = texi2pdf
# Where to find texinfo.tex to format documentation with TeX.
TEXIDIR = $(srcdir)/../texinfo
@@ -42,6 +43,7 @@
INFOFILES = standards.info
DVIFILES = standards.dvi
+PDFFILES = standards.pdf
all:
@@ -59,15 +61,19 @@
dvi: $(DVIFILES)
+pdf: $(PDFFILES)
+
standards.info: $(srcdir)/standards.texi $(srcdir)/make-stds.texi
$(MAKEINFO) --no-split -I$(srcdir) -o standards.info $(srcdir)/standards.texi
standards.dvi: $(srcdir)/standards.texi
TEXINPUTS=$(TEXIDIR):$$TEXINPUTS $(TEXI2DVI) $(srcdir)/standards.texi
+standards.pdf: $(srcdir)/standards.texi
+ TEXINPUTS=$(TEXIDIR):$$TEXINPUTS $(TEXI2PDF) $(srcdir)/standards.texi
clean:
- rm -f *.aux *.cp *.cps *.dvi *.fn *.fns *.ky *.kys *.log
+ rm -f *.aux *.cp *.cps *.dvi *.pdf *.fn *.fns *.ky *.kys *.log
rm -f *.pg *.pgs *.toc *.tp *.tps *.vr *.vrs
mostlyclean: clean
diff -ur gcc-2.95.2.old/gcc/Makefile.in gcc-2.95.2/gcc/Makefile.in
--- gcc-2.95.2.old/gcc/Makefile.in Fri Aug 13 09:46:55 1999
+++ gcc-2.95.2/gcc/Makefile.in Mon Dec 20 20:03:21 1999
@@ -2290,6 +2290,20 @@
texindex cpp.??
TEXINPUTS=${texidir}:$(srcdir):$$TEXINPUTS tex cpp.texi
+pdf: gcc.pdf cpp.pdf lang.pdf
+
+gcc.pdf: $(srcdir)/gcc.texi $(srcdir)/extend.texi $(srcdir)/install.texi \
+ $(srcdir)/invoke.texi $(srcdir)/md.texi $(srcdir)/rtl.texi \
+ $(srcdir)/tm.texi $(srcdir)/gcov.texi
+ TEXINPUTS=${texidir}:$(srcdir):$$TEXINPUTS pdftex gcc.texi
+ texindex gcc.??
+ TEXINPUTS=${texidir}:$(srcdir):$$TEXINPUTS pdftex gcc.texi
+
+cpp.pdf: $(srcdir)/cpp.texi
+ TEXINPUTS=${texidir}:$(srcdir):$$TEXINPUTS pdftex cpp.texi
+ texindex cpp.??
+ TEXINPUTS=${texidir}:$(srcdir):$$TEXINPUTS pdftex cpp.texi
+
INSTALL: $(srcdir)/install1.texi $(srcdir)/install.texi
cd $(srcdir); $(MAKEINFO) -D INSTALLONLY \
diff -ur gcc-2.95.2.old/gcc/ch/Make-lang.in gcc-2.95.2/gcc/ch/Make-lang.in
--- gcc-2.95.2.old/gcc/ch/Make-lang.in Fri Jun 25 10:26:19 1999
+++ gcc-2.95.2/gcc/ch/Make-lang.in Mon Dec 20 20:44:27 1999
@@ -106,6 +106,7 @@
CHILL.start.encap: chill
CHILL.rest.encap:
CHILL.dvi: chill.dvi
+CHILL.pdf: chill.pdf
CHILL.info: ch/chill.info
@@ -119,6 +120,14 @@
TEXINPUTS=${texidir}:$(srcdir):$$TEXINPUTS tex chill.texi
# FIXME: Not sure languages should do this.
cp ch/chill.dvi chill.dvi
+
+chill.pdf: $(srcdir)/ch/chill.texi $(srcdir)/extend.texi $(srcdir)/invoke.texi $(srcdir)/md.texi $(srcdir)/rtl.texi $(srcdir)/tm.texi
+ cd ch ; \
+ TEXINPUTS=${texidir}:$(srcdir):$$TEXINPUTS pdftex chill.texi ; \
+ texindex chill.?? ; \
+ TEXINPUTS=${texidir}:$(srcdir):$$TEXINPUTS pdftex chill.texi
+# FIXME: Not sure languages should do this.
+ cp ch/chill.pdf chill.pdf
#\f
# Install hooks:
# cc1chill is installed elsewhere as part of $(COMPILERS).
@@ -168,7 +177,7 @@
CHILL.extraclean:
CHILL.maintainer-clean:
-rm -f ch/TAGS
- -rm -f ch/chill.info* ch/chill.dvi ch/chill.??s ch/chill.*aux
+ -rm -f ch/chill.info* ch/chill.dvi ch/chill.pdf ch/chill.??s ch/chill.*aux
# CYGNUS LOCAL: Delete locally created file.
-rm -f ch/hash.h
#\f
diff -ur gcc-2.95.2.old/gcc/ch/Makefile.in gcc-2.95.2/gcc/ch/Makefile.in
--- gcc-2.95.2.old/gcc/ch/Makefile.in Wed Mar 31 09:47:58 1999
+++ gcc-2.95.2/gcc/ch/Makefile.in Mon Dec 20 20:44:59 1999
@@ -61,6 +61,7 @@
SHELL = /bin/sh
MAKEINFO = makeinfo
TEXI2DVI = texi2dvi
+TEXI2PDF = texi2pdf
# Define this as & to perform parallel make on a Sequent.
# Note that this has some bugs, and it seems currently necessary
diff -ur gcc-2.95.2.old/gcc/configure.in gcc-2.95.2/gcc/configure.in
--- gcc-2.95.2.old/gcc/configure.in Wed Oct 13 09:58:02 1999
+++ gcc-2.95.2/gcc/configure.in Mon Dec 20 20:45:38 1999
@@ -4226,7 +4226,7 @@
rm -f Make-hooks
touch Make-hooks
target_list="all.build all.cross start.encap rest.encap \
- info dvi \
+ info dvi pdf \
install-normal install-common install-info install-man \
uninstall distdir \
mostlyclean clean distclean extraclean maintainer-clean \
diff -ur gcc-2.95.2.old/gcc/cp/Make-lang.in gcc-2.95.2/gcc/cp/Make-lang.in
--- gcc-2.95.2.old/gcc/cp/Make-lang.in Tue Apr 27 01:50:36 1999
+++ gcc-2.95.2/gcc/cp/Make-lang.in Mon Dec 20 20:31:09 1999
@@ -132,6 +132,7 @@
c++.info:
c++.dvi:
+c++.pdf:
# C++ language-support library pieces for libgcc.
tinfo.o: cc1plus$(exeext) $(srcdir)/cp/tinfo.cc
diff -ur gcc-2.95.2.old/gcc/cp/Makefile.in gcc-2.95.2/gcc/cp/Makefile.in
--- gcc-2.95.2.old/gcc/cp/Makefile.in Sun Jul 25 23:27:38 1999
+++ gcc-2.95.2/gcc/cp/Makefile.in Mon Dec 20 20:31:31 1999
@@ -68,6 +68,7 @@
SHELL = /bin/sh
MAKEINFO = makeinfo
TEXI2DVI = texi2dvi
+TEXI2PDF = texi2pdf
# Define this as & to perform parallel make on a Sequent.
# Note that this has some bugs, and it seems currently necessary
diff -ur gcc-2.95.2.old/gcc/f/Make-lang.in gcc-2.95.2/gcc/f/Make-lang.in
--- gcc-2.95.2.old/gcc/f/Make-lang.in Mon Jun 7 08:44:57 1999
+++ gcc-2.95.2/gcc/f/Make-lang.in Mon Dec 20 20:48:33 1999
@@ -52,7 +52,7 @@
# Tell GNU make to ignore these if they exist.
.PHONY: F77 f77 f77.all.build f77.all.cross \
- f77.start.encap f77.rest.encap f77.info f77.dvi \
+ f77.start.encap f77.rest.encap f77.info f77.dvi f77.pdf\
f77.install-normal \
f77.install-common f77.install-info f77.install-man \
f77.uninstall f77.mostlyclean f77.clean f77.distclean \
@@ -250,6 +250,26 @@
TEXINPUTS=$(srcdir)/f:$$TEXINPUTS tex $(srcdir)/f/g77.texi; \
mv g77.dvi f; \
else true; fi
+
+f/g77.pdf: $(srcdir)/f/g77.texi $(srcdir)/f/bugs.texi \
+ $(srcdir)/f/ffe.texi \
+ $(srcdir)/f/g77install.texi $(srcdir)/f/news.texi \
+ $(srcdir)/f/intdoc.texi $(srcdir)/f/root.texi
+ case "$(LANGUAGES)" in \
+ *[fF]77*) touch lang-f77;; \
+ *) rm -f lang-f77;; \
+ esac
+# `tex2dvi' was used below, but the Texinfo 3.12 one won't work properly
+# with the include files from $(srcdir). This use of TEXINPUTS may not
+# be universally valid. `$(TEX)' should be used if it gets defined in
+# gcc/Makefile.in.
+ if [ -f lang-f77 ]; then \
+ TEXINPUTS=$(srcdir)/f:$$TEXINPUTS pdftex $(srcdir)/f/g77.texi; \
+ texindex g77.??; \
+ TEXINPUTS=$(srcdir)/f:$$TEXINPUTS pdftex $(srcdir)/f/g77.texi; \
+ mv g77.dvi f; \
+ else true; fi
+
# This dance is all about producing accurate documentation for g77's
# intrinsics with minimum fuss. f/ansify appends "\n\" to C strings
diff -ur gcc-2.95.2.old/gcc/f/Makefile.in gcc-2.95.2/gcc/f/Makefile.in
--- gcc-2.95.2.old/gcc/f/Makefile.in Wed Dec 16 22:16:32 1998
+++ gcc-2.95.2/gcc/f/Makefile.in Mon Dec 20 20:46:32 1999
@@ -64,6 +64,7 @@
SHELL = /bin/sh
MAKEINFO = makeinfo
TEXI2DVI = texi2dvi
+TEXI2DVI = texi2pdf
# Define this as & to perform parallel make on a Sequent.
# Note that this has some bugs, and it seems currently necessary
Only in gcc-2.95.2/gcc/intl: #Makefile.in#
Only in gcc-2.95.2: pdfs
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~1999-12-31 23:54 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-12-21 3:22 Data on PDF vs PS (Was Re: Online docs page should ..) [With prelim patch] Jan Vroonhof
1999-12-22 10:15 ` Marc Lehmann
1999-12-22 15:36 ` Geoff Keating
1999-12-31 23:54 ` Geoff Keating
1999-12-31 23:54 ` Marc Lehmann
1999-12-31 23:54 ` Jan Vroonhof
-- strict thread matches above, loose matches on Subject: below --
1999-12-20 12:57 Jan Vroonhof
1999-12-20 13:55 ` Marc Lehmann
1999-12-31 23:54 ` Marc Lehmann
1999-12-31 23:54 ` Jan Vroonhof
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).