Re: ANNOUNCE: Xpdf 2.02 - a PDF viewer for X
On 2003-03-24 19:58:02 -0000, Derek B. Noonburg wrote:
Glyph & Cog, LLC is pleased to announce a new version of Xpdf, the open source Portable Document Format (PDF) viewer for X. The Xpdf project also includes a PDF text extractor, PDF-to-PostScript converter, and various other utilities.
Xpdf runs under the X Window System on Unix, VMS, and OS/2. The non-X components (pdftops, pdftotext, etc.) also run on Win32 systems and should run on pretty much any system with a decent C++ compiler.
Major changes: * Rewrote the text extractor code that assembles words into lines to better handle vertically overlapping lines. * Add the "match" option for paper size (in PostScript output). * Added support for external 16-bit TrueType fonts; added the displayCIDFontTT and displayNamedCIDFontTT commands to the xpdfrc file. * Added an Arabic language support package. * Added the Windows-1255 encoding to the Hebrew language package.
See the `CHANGES' file for a complete list of changes.
I'll integrate it next week (i.e. hopefully before DANTE2003) and thus start work on 1.11a Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10
Hi pdftex fans, on my homepage you find a VERY buggy rough try on a socket interface for (but not limited to) pdftex. This allows to type something like: \socketmodeon 5 \def\serverport{ftp.someserver.com:21} % watch the colon :-) \immediate\openout 5 = \serverport \immediate\openin 5 = \serverport \immediate\write 5 {something} \immediate\read 5 to \xyz % whatever the server does from "something" \xyz The problem is, well, that it's VERY buggy, in fact nothing more than a rough sketch, but anyway, it made its 1st PDF file, and I thought when it's out we might find some minute to discuss and scrap it unanimously. See you... Hartmut ------------------------------------------------------------------------ Dr.-Ing. Hartmut Henkel Oftersheim, Germany E-Mail: hartmut_henkel@gmx.de http://www.circuitwizard.de ------------------------------------------------------------------------
Hi all,
Cool. Fabrice, didn't you work on something similar? I remember you
showing me some work you were doing on use of URLs in TeX documents
at EuroTeX 2001 (in Kerkrade). Whatever became of that?
Hartmut, some comments:
How cross platform is this? I am not a windows programmer (only
work on UNIX), so I do not know if there are sockets available on
Windows. And for a Macintosh port (MacOS 9, anyway), GUSI would
be needed (there is Macintosh port of GUSI to layer sockets on
top of the streams interface that OpenTransport uses).
What about use of poll/select for many different connections, etc?
Tom
On 2003/03/30 at 22:29, Hartmut Henkel
Hi pdftex fans,
on my homepage you find a VERY buggy rough try on a socket interface for (but not limited to) pdftex. This allows to type something like:
\socketmodeon 5 \def\serverport{ftp.someserver.com:21} % watch the colon :-) \immediate\openout 5 = \serverport \immediate\openin 5 = \serverport \immediate\write 5 {something} \immediate\read 5 to \xyz % whatever the server does from "something" \xyz
The problem is, well, that it's VERY buggy, in fact nothing more than a rough sketch, but anyway, it made its 1st PDF file, and I thought when it's out we might find some minute to discuss and scrap it unanimously.
On Sun, 30 Mar 2003, Tom Kacvinsky wrote:
How cross platform is this?
Likely portable to other UNIXes, but it should work first :-)
I am not a windows programmer (only work on UNIX), so I do not know if there are sockets available on Windows.
Same with me, happily using debian Linux, and I didn't spend a second thinking about Redmond.
And for a Macintosh port (MacOS 9, anyway), GUSI would be needed (there is Macintosh port of GUSI to layer sockets on top of the streams interface that OpenTransport uses). What about use of poll/select for many different connections, etc?
Don't know, it's my first try ever on sockets/select :-) Saw poll first in your mail, found the man page. TeX itself works sequentially, so it anyway reads one stream after the other. And it's the master querying things, not the other way around. But one can have more than 1 socket open. Greetings Hartmut
On 2003-03-25 10:29:40 +0100, Martin Schröder wrote:
I'll integrate it next week (i.e. hopefully before DANTE2003) and thus start work on 1.11a
It's finally done. Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10
Hi, I just found out that the old version was capable of spontaniously adding crap between ">>" and "stream" which somehow was accepted by viewers but nevertheless incorrect; the new version is ok in this respect; i don't know if that was a known bug (or mem leak or so); if not we've got another bug solved -) Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
On 2003-04-22 16:12:13 +0200, Hans Hagen wrote:
nevertheless incorrect; the new version is ok in this respect; i don't know if that was a known bug (or mem leak or so); if not we've got another bug
Probably a mem leak. IIRC I fixed some of them in 1.10b. :-) Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10
This is not a bug at all, IMHO just a little bit of redundant code in the pdf output: The rule-drawing by pdf_set_rule(), 2nd else clause, brackets also the "re f" box drawing by "q []0d 0 J" and "S Q", which is not required, as filling commands ignore dash and linecap info, and there is also nothing to Stroke. Therefore one can completely omit the grouping. I have tried it and could not find any difference in appearence. The patch would be easy, see below. Greetings Hartmut --- pdftex.ch.orig Thu Mar 27 22:10:26 2003 +++ pdftex.ch Wed May 7 23:16:10 2003 @@ -1675,31 +1675,34 @@ begin pdf_end_text; pdf_set_origin; - pdf_print_ln("q"); - pdf_print_ln("[]0 d"); - pdf_print_ln("0 J"); if h <= one_bp then begin + pdf_print_ln("q"); + pdf_print_ln("[]0 d"); + pdf_print_ln("0 J"); pdf_print_bp(h); pdf_print_ln(" w"); pdf_print("0 "); pdf_print_bp((h + 1)/2); pdf_print_ln(" m"); pdf_print_bp(w); pdf_print(" "); pdf_print_bp((h + 1)/2); pdf_print_ln(" l"); + pdf_print_ln("S"); + pdf_print_ln("Q"); end else if w <= one_bp then begin + pdf_print_ln("q"); + pdf_print_ln("[]0 d"); + pdf_print_ln("0 J"); pdf_print_bp(w); pdf_print_ln(" w"); pdf_print_bp((w + 1)/2); pdf_print_ln(" 0 m"); pdf_print_bp((w + 1)/2); pdf_print(" "); pdf_print_bp(h); pdf_print_ln(" l"); + pdf_print_ln("S"); + pdf_print_ln("Q"); end else begin - pdf_print_ln("0 j"); - pdf_print_ln("0 w"); pdf_print_bp(pdf_x(x)); pdf_out(" "); pdf_print_bp(pdf_y(y)); pdf_out(" "); pdf_print_bp(w); pdf_out(" "); pdf_print_bp(h); pdf_print_ln(" re f"); end; - pdf_print_ln("S"); - pdf_print_ln("Q"); end; ------------------------------------------------------------------------ Dr.-Ing. Hartmut Henkel Oftersheim, Germany E-Mail: hartmut_henkel@gmx.de http://www.circuitwizard.de ------------------------------------------------------------------------
At 21:29 08/05/2003 +0200, Hartmut Henkel wrote:
This is not a bug at all, IMHO just a little bit of redundant code in the pdf output: The rule-drawing by pdf_set_rule(), 2nd else clause, brackets also the "re f" box drawing by "q []0d 0 J" and "S Q", which is not required, as filling commands ignore dash and linecap info, and there is also nothing to Stroke. Therefore one can completely omit the grouping. I have tried it and could not find any difference in appearence.
The patch would be easy, see below.
ah, this is a left over form the time that thanh and i were torture testing the different methods with regards to rendering (printing, previewing, etc), Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
Interesting! What in short is the story of using stroke or fill depending on line width? Hartmut On Thu, 8 May 2003, Hans Hagen wrote:
At 21:29 08/05/2003 +0200, Hartmut Henkel wrote:
ah, this is a left over form the time that thanh and i were torture testing the different methods with regards to rendering (printing, previewing, etc),
Hans
On 2003-05-08 21:29:24 +0200, Hartmut Henkel wrote:
The patch would be easy, see below.
It's in (#3305) Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10
participants (4)
-
Hans Hagen -
Hartmut Henkel -
Martin Schroeder -
Tom Kacvinsky