Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page
Thread view  Board view
Rugxulo(R)

Homepage

Usono,
19.05.2012, 04:24
 

XPDF 3.03 (DJGPP) (Announce)

Thanks to Georg's suggestion and tiny patch, I've been able to compile latest XPDF 3.03 via DJGPP. I've uploaded the binaries and sources to iBiblio.

Website: http://www.foolabs.com/xpdf/
Download: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/xpdf/

The original release was on 15 August 2011 and no longer has DJGPP binaries (for whatever reason), though support still exists in sources. It is dually licensed under GPLv2 or GPLv3 (but not "or later").

N.B. I've not tested this very well, but it does seem to work, at least pdftotext.exe. I'm not a big PDF collector, so most of the ones I have are programming-related and only spec 1.5 or older (though Xpdf can allegedly support at least up through 1.7 or such). New binary in this release is pdfextract.exe for attachments. For pdftoppm.exe, I've not tried compiling, but it needs FreeType fonts, minimum, so that may or may not work, dunno.

RayeR(R)

Homepage

CZ,
19.05.2012, 15:04

@ Rugxulo
 

XPDF 3.03 (DJGPP)

> Thanks to Georg's suggestion and tiny patch, I've been able to compile
> latest XPDF 3.03 via DJGPP. I've uploaded the binaries and sources
> to iBiblio.

Nice, I still have some thoughts and tries with MuPDF (currently 0.8), e.g. I fixed RGB-BGR color channels flip but still I have messed MTRR code in my lib so I don't want release it yet (Laaca had tested). But probably it doesn't have sense release it when Xpdf is here. Maybe I can compare display speed on older machines if it performs better due to less overhead...

---
DOS gives me freedom to unlimited HW access.

Rugxulo(R)

Homepage

Usono,
19.05.2012, 20:03

@ RayeR
 

XPDF 3.03 (DJGPP)

> Nice, I still have some thoughts and tries with MuPDF (currently 0.8), e.g.
> I fixed RGB-BGR color channels flip but still I have messed MTRR code in my
> lib so I don't want release it yet (Laaca had tested).

Why not leave out MTRR fiddling? Let Japheth's VESAMTRR util handle it externally and don't worry with it.

> But probably it doesn't have sense release it when Xpdf is here.

Non-X11 builds like this don't have the actual "xpdf" viewer. So at best, for us, it's only a cmdline converter, as is. Not bad but very indirect.

> Maybe I can compare display speed on older machines if it performs better due to less overhead...

Compared to older MuPDF or XPDF? As mentioned, this build is cmdline tools only, so I doubt it's "faster" than yours, heh. :-)

Doug(R)

E-mail

19.05.2012, 22:12

@ Rugxulo
 

XPDF 3.03 (DJGPP)

Yes, please don't abandon MuPDF DOS -- it *is* more direct, self-contained, cleaner, and quicker than creating intermediate files via XPDF and Ghostscript, and then using an image viewer. But the separate XPDF and MuPDF command-line tools are useful in their own ways as well. I'm glad we have such choices in modern-day DOS.

JFYI, there have been many updates of MuPDF since v0.8 -- mostly bugfixes, but v0.8.165 added XPS abilities, and 1.0 contains significant source-code changes (which seem to be improvements, but i don't know how they will impact DOS compilation).

Anyway, here's the MuPDF release timeline:

MuPDF 1.0 (2012-04-24)
MuPDF 0.9 (2011-09-05)
MuPDF 0.8.165 (2011-04-29)
MuPDF 0.8.15 (2011-03-15)
MuPDF 0.8 (2011-03-03)

You can read about the specific changes under "News" at the main site:

http://mupdf.com/

Thanks to all....

- Doug B.

RayeR(R)

Homepage

CZ,
20.05.2012, 01:09

@ Doug
 

XPDF 3.03 (DJGPP)

> MuPDF 1.0 (2012-04-24)
> MuPDF 0.9 (2011-09-05)
> MuPDF 0.8.165 (2011-04-29)
> MuPDF 0.8.15 (2011-03-15)
> MuPDF 0.8 (2011-03-03)

Currently I work on MuPDF 0.8.15, newer versions have changed source tree structure a lot and I can't compile it (hate damn configure shits...). Is there some difference in supported versions of PDF documents?

---
DOS gives me freedom to unlimited HW access.

Doug(R)

E-mail

20.05.2012, 23:28

@ RayeR
 

XPDF 3.03 (DJGPP)

> Currently I work on MuPDF 0.8.15, newer versions have changed source tree
> structure a lot and I can't compile it (hate damn configure shits...).

Krap... ok, i know what you mean.

The reason for my original posting is that there seemed to me to be another -- major -- change in coding between v0.9 and v1.0. I'm wondering if that might make it more compatible again?

Here's the significant changes that i see from looking at their page:

* Removal of all global variables: we now pass a context pointer through
  the code freeing us from the use of globals within the library.
* New error handling: a portable exception-like system is used to allow
  neater handling of errors. This leads to more stability and better
  resilience to broken files.
* Public/Private API: the API has undergone a significant revision
  (required by some of the above changes, plus renaming/revising for
  clarity and consistency), and has been split into public and private
  headers. The plan is that the public portion of the API should remain
  much more static in future.
* Documentation: All public header entry points/structures are now
  documented and overviews of how to call the library to render pages
  both in single and multi-threaded mode are given.
* Many, many, bugfixes.

> Is there some difference in supported versions of PDF documents?

None that they mention on their history page. Other than the support for XPS documents beginning in v0.8.165.

But all in all... version 0.8.15 is a million times better than having *no* MuPDF! :ok: Appreciation for all your work....

- Doug B.

RayeR(R)

Homepage

CZ,
20.05.2012, 01:06

@ Rugxulo
 

XPDF 3.03 (DJGPP)

> Why not leave out MTRR fiddling? Let Japheth's VESAMTRR util handle it
> externally and don't worry with it.

It's releated to 4GB RAM and more systems, see older post. There's no any DOS utility that can set it properly yet so I have to finish it.

> Non-X11 builds like this don't have the actual "xpdf" viewer. So at best,
> for us, it's only a cmdline converter, as is. Not bad but very indirect.

Aha, I though it was FLTK port with GUI (saw on screenshot that xpdf has a GUI).

---
DOS gives me freedom to unlimited HW access.

georgpotthast(R)

Homepage

Germany,
20.05.2012, 09:21

@ RayeR
 

XPDF 3.03 (DJGPP)

> > Why not leave out MTRR fiddling? Let Japheth's VESAMTRR util handle it
> > externally and don't worry with it.
>
> It's releated to 4GB RAM and more systems, see older post. There's no any
> DOS utility that can set it properly yet so I have to finish it.
>
> > Non-X11 builds like this don't have the actual "xpdf" viewer. So at
> best,
> > for us, it's only a cmdline converter, as is. Not bad but very indirect.
>
> Aha, I though it was FLTK port with GUI (saw on screenshot that xpdf has a
> GUI).

The xpdf GUI uses Motif and I did not port that to DOS.

However, I am working on a port of mupdf to DOS using NXlib.

Georg

georgpotthast(R)

Homepage

Germany,
21.05.2012, 20:53

@ georgpotthast
 

MUPDF with NXlib released

I just released my first version of MUPDF compiled with NXlib for DOS. It is based on mupdf version 0.7

Georg

download link

Rugxulo(R)

Homepage

Usono,
22.05.2012, 00:57

@ georgpotthast
 

MUPDF with NXlib released

> I just released my first version of MUPDF compiled with NXlib for DOS. It
> is based on mupdf version 0.7
>
> download
> link

This works pretty darn well, surprisingly well, thanks.

Two very minor (nitpicky, annoying) tips: 1). "upx --best --lzma" (as is it's currently only --best, so wasteful, heheh), 2). "mupdf blah.pdf 3" will go to page three (which GO.BAT doesn't mention).

P.S. RayeR, Zyzzle is at least somewhat right, yours does work on >4 GB machines like mine. However, if it's that important to you, you can always use a DXE and plug in the MTRR fixes later on. (I don't really expect you to do this, but I guess that's as good a use as any for existence of DXEs.)

RayeR(R)

Homepage

CZ,
22.05.2012, 15:59

@ georgpotthast
 

MUPDF with NXlib released

> I just released my first version of MUPDF compiled with NXlib for DOS. It
> is based on mupdf version 0.7
>
> Georg
>
> download
> link

I did a quick test and it seems to run ok but we have some common problems (I currently migrated to 0.9 but same result)
http://rayer.g6.cz/1tmp/testpdf/a2.pdf - strange color mess-up, esp.pg.7 (not a simple channel flip)
http://rayer.g6.cz/1tmp/testpdf/a5-crash.pdf - do crash (textmode pdfdraw.exe too) but mupdf win32 works. But I don't have time to track this problem.

---
DOS gives me freedom to unlimited HW access.

georgpotthast(R)

Homepage

Germany,
22.05.2012, 21:14

@ RayeR
 

MUPDF with NXlib released

I looked at a2.pdf but I could just see a lower resolution than on my Windows PC.

As with a5-crash.pdf, just the pages that have color, or some tiny rest of color, do crash. So
"mupdf a5-crash 10"
will not crash, since it skips the first pages with color. The following pages will cause a crash: 1,2,3,9,73,105,124,137,151,156 and 157. I observed that the "Google" image will build up while opening the document on windows, so maybe mupdf does not support this type of colored image in this release.

I guess if one would port a later version of mupdf this problem may be fixed.

Georg

RayeR(R)

Homepage

CZ,
23.05.2012, 00:03

@ georgpotthast
 

MUPDF with NXlib released

> I looked at a2.pdf but I could just see a lower resolution than on my
> Windows PC.

I viewed on windows in Adobe Reader 9.0 at work and colors of loopback wires on connector on page 7 looked very different. But now I looked at home on windows and it looks OK...

> As with a5-crash.pdf, just the pages that have color, or some tiny rest of
> color, do crash. So
> "mupdf a5-crash 10"
> will not crash, since it skips the first pages with color. The following
> pages will cause a crash: 1,2,3,9,73,105,124,137,151,156 and 157. I
> observed that the "Google" image will build up while opening the document
> on windows, so maybe mupdf does not support this type of colored image in
> this release.

> I guess if one would port a later version of mupdf this problem may be
> fixed.

But win32 version of the same MuPDF can view all pages without crash! It's issue of DOS version only. I updated to latest 3rd party libraries that MuPDF use but no change.

---
DOS gives me freedom to unlimited HW access.

DOS386(R)

12.07.2016, 07:59

@ RayeR
 

MUPDF with NXlib released

> I just released my first version of MUPDF compiled with
> NXlib for DOS. It is based on mupdf version 0.7

[image]

FYI, I tested now (after only 4 years) and got some results.

+ Georg's binary is a bit better than RayeR's one (thanks to both)
- the only malicious issue are the crashing pages, they are very same for RayeR's binary, Georg's binary and the Win32 binary
- sometimes the program leaves a broken screen on crash (bad)
- some further very minor issues RTFW

> will not crash, since it skips the first pages with color. The following
> pages will cause a crash: 1,2,3,9,73,105,124,137,151,156 and 157

> But win32 version of the same MuPDF can view all pages without crash! It's
> issue of DOS version only

I downloaded RayeR's broken PDF's (still available) and will test them too.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386(R)

13.07.2016, 17:13

@ DOS386
 

BUG diagnosis (MU 0.7)

> I downloaded RayeR's broken PDF's (still available) and will test

Done!

> http://rayer.g6.cz/1tmp/testpdf/a2.pdf - strange color mess-up,
> esp.pg.7 (not a simple channel flip)

I can't confirm that. Worx fine for me. RayeR's binary R<->B channel flip, Georg's binary OK.

> http://rayer.g6.cz/1tmp/testpdf/a5-crash.pdf - do crash (textmode pdfdraw.exe
> too) but mupdf win32 works. But I don't have time to track this problem.

Indeed:
RayeR's binary -> CRASH just on page 1
Georg's binary -> CRASH just on page 1
Win32 binary -> OK

Well ... actually NOT OK with Win32 binary. Page 1 has other size than following pages, but this is NOT the problem. The problem is something else: a brutal memory leak MU 0.7 code base. After a few pages the memory consumption grows up to only cca 700 MiO and then it crashes (apparently I have 1 GiO RAM). With MU 0.9 the memory consumption grows up to cca 70 MiO only, this is still ridiculously much, but already much better than 0.7. Other documents need only cca 7 MiO RAM.

For some reason, the both DOS ports crash immediately while the Win32 binary doesn't, but the official code base is definitely guilty. The DOS ports just better expose an existing BUG. Updating the DOS port with 0.9 codebase would much improve the situation. But I still don't like the 70 MiO needed by MU 0.9. I don't know whether the document is faulty or 0.9 still has a memory problem.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Zyzzle(R)

20.05.2012, 23:17

@ RayeR
 

XPDF 3.03 (DJGPP)

> Nice, I still have some thoughts and tries with MuPDF (currently 0.8), e.g.
> I fixed RGB-BGR color channels flip but still I have messed MTRR code in my
> lib so I don't want release it yet (Laaca had tested). But probably it
> doesn't have sense release it when Xpdf is here. Maybe I can compare
> display speed on older machines if it performs better due to less
> overhead...

I also say, please continue with MuPDF project in spite of MTRR code problems. Anyway, I thought the > 4GB problems were (mostly) fixed, as I had done some testing before... Anyway, it is a great way to view PDFs in DOS (but, please release the RGB-BGR fix, that's an annoying problem!) and, along with XPDP 3.03, now we have a complete PDF viewer / extractor / info package for our beloved DOS systems.

DOS386(R)

13.06.2012, 11:24

@ Rugxulo
 

XPDF 3.03 (DJGPP) + MUPDF

> able to compile latest XPDF 3.03 via DJGPP

PDFDETACH.EXE is in (untested, and too long), PDFTOPPM.EXE not :-|

About MUPDF, there are substantial quality improvemens from 0.7 to 0.9 (PDFDRAW.EXE from 0.9 works in DOS).

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386(R)

05.11.2012, 03:43

@ DOS386
 

MuPDF 1.1 (2012-08-16)

MuPDF 1.1 is out (oops, 3 months ago). What's new:

* The command line tools have been combined into one tool that does all: mubusy
* Some BUG's got fixed

Untested (commandline tools from 0.9 do work in DOS).

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Rugxulo(R)

Homepage

Usono,
27.04.2013, 02:56

@ DOS386
 

MuPDF 1.2 (2013-02-27)

> MuPDF 1.1 is out (oops, 3 months ago). What's new:
>
> * The command line tools have been combined into one tool that does all:
> mubusy
> * Some BUG's got fixed
>
> Untested (commandline tools from 0.9 do work in DOS).

MuPDF 1.2 was released in late February. Various changes, not the least of which is renaming to "mutool" instead of "mubusy". Yes, default mutool and mudraw Win32 binaries seem to (upon very light testing) still work under HX, but the others don't. I'm honestly not sure how useful it is for us (compared to older Ghostscript or XPDF), but apparently you can (cross-)compile for DOS via DJGPP, at least for those two cmdline tools (see below).

FYI, I'm very very noobish about all this document, markup, printer, typeface stuff. But here's some quick comments:

1). PostScript is still vaguely popular, but PDF has more or less matched it in popularity. They've already ISO standardized PDF (1.7-ish) and subsets in the past handful of years, but I don't think PostScript (level 3) will be updated much in the future, if at all. Adobe seems to consider PDF superior and have even been (optionally) offering native printer support for it. Everything you wanted to know about PDF but were afraid to ask (2012).

(Most of the few .PDFs I have are for references for various programming languages or similar. Sometimes they are bloated quite badly, not exactly sure why, but some tools must thing converting the textual data per page to a bunch of graphical images is a good idea, even when no diagrams or other images are needed. Seems overkill just for a little formatting. Also, embedding hundreds of fonts is, um, bad [Georg, any idea??]. It seems like overkill sometimes when a simple HTML subset would suffice.)

2). PostScript seems mainly for printing hard copies. A lot of tools are used to convert back and forth between it (and others). TeX, Lout, Halibut, GNU enscript, GNU a2ps, etc. etc. (It's quite confusing how many there are.) Ghostscript of course can do ps2pdf, but it works a bit worse in the DOS versions (not sure why).

3). It seems like Ghostscript and MuPDF are somehow connected these days (Artifex). Also the various licensing changes over the years are confusing. Not sure what's different in GNU Ghostscript, but clearly (as has been mentioned before) none of these directly support DOS anymore (or at least not VESA drivers). Latest seems to be 9.07 (and 9.06 for GNU), but FreeDOS only has some older versions (and I don't know how well-supported or decently they work overall, not sure how to fully test them), e.g. from iBiblio's /util/file/gs/ : 2.6.1, 4.03, 5.10, 7.05, 8.55, 8.71. IIRC, some of these are old 16-bit, some are 32-bit Watcom, some are DJGPP v2. I have no idea how easy it would be to rebuild some of these. Also, Mateusz's DOSPDF (/util/file/dospdf) meta-package (circa 2007) used old Watcom 5.10 while Georg's FLW12.ZIP from last year uses Watcom 7.05. Apparently some things (either fonts or table files or whatever crud) aren't compatible across major versions.

4). I don't really like the idea of generating separate (bloated) image files for each page of a PDF, but it's much better than nothing. No offense to our very honorable brethren who have ported MuPDF to DOS GUI tools before, but they leave a lot to be desired. So I guess the various ways would be to use MuPDF viewer (either RayeR or Georg), old DOS Ghostscript (which), or mudraw to convert to separate image files, or just use XPDF (pdftotext) to convert to plain text. Georg's FLW12 also had pdf2html, which is kinda old (2006-ish separate fork of XPDF?), but maybe that's useful too, dunno, not sure how much it saves in the translation (and I haven't tried compiling that).

5). In other words, MUTOOL.EXE and MUDRAW.EXE for DJGPP v2 are each very big .EXEs (approx. 9 MB each, 3.5 MB UPX'd) and not exactly directly useful (unless you like workarounds like separate images and image viewers, which there are many but most aren't very user-friendly). I don't know if that's really more useful than the existing two MuPDF viewers we have, nor if somehow better than XPDF or Ghostscript converters.


(Fri Apr 26, 07:43 PM) /tmp/doydoy # upx -qql /mnt/sda3/TEMP/*.exe
   8922407 ->   3307752   37.07%   djgpp2/coff   /mnt/sda3/TEMP/mudraw.exe
   8785024 ->   3256728   37.07%   djgpp2/coff   /mnt/sda3/TEMP/mutool.exe


Though if anyone really wants, I will upload MUTOOL.EXE and MUDRAW.EXE for them somewhere. Full source .ZIP with needed third-party libs is 13 MB, which due to GNU AGPL is more ballast to host with binaries, ugh. Lemme see if unpacking everything and repacking with 7-Zip would help ... 8 MB .7z (including binaries), but I think dictionary size is 2^26, aka 67 MB. Still, better than 20 MB for a .ZIP of the source .ZIP plus UPX'd .EXEs.

Here's the (very stupid) tiny patch I used (with lrintf from newlib) to cross-compile them via uHexen2 dude's Linux-hosted DJGPP-targeted toolset:


diff -waruN mupdf-1.2-source/makedj.sh mupdf-1.2-djgpp-cross/makedj.sh
--- mupdf-1.2-source/makedj.sh  1969-12-31 18:00:00.000000000 -0600
+++ mupdf-1.2-djgpp-cross/makedj.sh     2013-04-26 08:16:20.000000000 -0500
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+# using Ozkan Sezer's cross-GCC for DJGPP (2.04 from CVS and GCC/G++ 3.4.6)
+make generate
+make OS=djgpp build=release
+upx --best --lzma build/release/*.exe
diff -waruN mupdf-1.2-source/Makerules mupdf-1.2-djgpp-cross/Makerules
--- mupdf-1.2-source/Makerules  2013-02-13 08:25:07.000000000 -0600
+++ mupdf-1.2-djgpp-cross/Makerules     2013-04-26 08:11:53.000000000 -0500
@@ -70,6 +70,15 @@
 #   2) do a non cross compile build (e.g. windows in MSVC) first.
 #   3) download the generated files from mupdf.com.
 
+ifeq "$(OS)" "djgpp"
+CC = i586-pc-msdosdjgpp-gcc
+LD = i586-pc-msdosdjgpp-gcc
+AR = i586-pc-msdosdjgpp-ar
+CFLAGS += -O3 -mtune=i686 -ffast-math -fsingle-precision-constant
+CROSSCOMPILE=yes
+NOX11=yes
+endif
+
 ifeq "$(OS)" "beagle-cross"
 CC = arm-none-linux-gnueabi-gcc
 LD = arm-none-linux-gnueabi-gcc
diff -waruN mupdf-1.2-source/thirdparty/openjpeg/libopenjpeg/lrintf.h mupdf-1.2-djgpp-cross/thirdparty/openjpeg/libopenjpeg/lrintf.h
--- mupdf-1.2-source/thirdparty/openjpeg/libopenjpeg/lrintf.h   1969-12-31 18:00:00.000000000 -0600
+++ mupdf-1.2-djgpp-cross/thirdparty/openjpeg/libopenjpeg/lrintf.h      2013-04-26 08:01:04.000000000 -0500
@@ -0,0 +1,22 @@
+#if defined(__GNUC__) && !defined(_SOFT_FLOAT)
+
+#include <math.h>
+
+/*
+ * Fast math version of lrintf(x)
+ * Return x rounded to integral value according to the prevailing
+ * rounding mode.
+ * Method:
+ *    Using inline x87 asms.
+ * Exception:
+ *    Governed by x87 FPCR.
+ */
+
+long int lrintf (float x)
+{
+  long int _result;
+  asm ("fistpl %0" : "=m" (_result) : "t" (x) : "st");
+  return _result;
+}
+
+#endif  /* !__GNUC__ || _SOFT_FLOAT */
\ No newline at end of file
diff -waruN mupdf-1.2-source/thirdparty/openjpeg/libopenjpeg/tcd.c mupdf-1.2-djgpp-cross/thirdparty/openjpeg/libopenjpeg/tcd.c
--- mupdf-1.2-source/thirdparty/openjpeg/libopenjpeg/tcd.c      2013-02-13 08:25:32.000000000 -0600
+++ mupdf-1.2-djgpp-cross/thirdparty/openjpeg/libopenjpeg/tcd.c 2013-04-26 08:12:51.000000000 -0500
@@ -30,6 +30,10 @@
  * POSSIBILITY OF SUCH DAMAGE.
  */
 
+#ifdef __DJGPP__
+#include "lrintf.h" // patch for C99 func (since DJGPP doesn't have it [yet?])
+#endif
+
 #include "opj_includes.h"
 
 void tcd_dump(FILE *fd, opj_tcd_t *tcd, opj_tcd_image_t * img) {

Rugxulo(R)

Homepage

Usono,
28.04.2013, 10:50

@ Rugxulo
 

MuPDF 1.2 (2013-02-27)

> MuPDF 1.2 was released in late February.
> Various changes, not the least of
> which is renaming to "mutool" instead of "mubusy". Yes, default mutool and
> mudraw Win32 binaries seem to (upon very light testing) still work under
> HX, but the others don't. I'm honestly not sure how useful it is for us
> (compared to older Ghostscript or XPDF), but apparently you can
> (cross-)compile for DOS via DJGPP, at least for those two cmdline tools
> (see below).

MUDRAW can convert to .PNG, but I'm not sure of the best viewer for that (QPNG? Pictview? Blocek?) Or just use some converter (Image Magick?) for different format.

> 3). It seems like Ghostscript and MuPDF are somehow connected these days
> (Artifex). Also the various licensing changes over the years are confusing.
> Not sure what's different in GNU Ghostscript, but clearly (as has been
> mentioned before) none of these directly support DOS anymore (or at least
> not VESA drivers).

Was VESA support only in Watcom versions? Only in Kostylev's builds?

> Latest seems to be 9.07 (and 9.06 for GNU), but FreeDOS
> only has some older versions (and I don't know how well-supported or
> decently they work overall, not sure how to fully test them), e.g. from
> iBiblio's /util/file/gs/ : 2.6.1, 4.03, 5.10, 7.05, 8.55, 8.71. IIRC, some
> of these are old 16-bit, some are 32-bit Watcom, some are DJGPP v2. I have
> no idea how easy it would be to rebuild some of these. Also, Mateusz's
> DOSPDF (/util/file/dospdf) meta-package (circa 2007) used old Watcom 5.10
> while Georg's FLW12EXT.ZIP from last year uses Watcom 7.05. Apparently some
> things (either fonts or table files or whatever crud) aren't compatible
> across major versions.

There is also a 7.05 with DJGPP by Caddit.net (PythonD) dude, but I don't know if it's better or not. 8.55 seems to be Michael Kostylev's (DJGPP) port. 8.71 (DJGPP, Perotti?) seems rougher and buggier but still somewhat works.

It seems that "ps2pdf" is quite horribly inefficient in 7.05, e.g. seems to embed way too many fonts. (Georg, this is what I meant, any idea?) This seems to have been "fixed" in 8.x (DOS) versions, though 8.71 seems to only have Bash script drivers (ugh) in lieu of .BATs.

> 5). In other words, MUTOOL.EXE and MUDRAW.EXE for DJGPP v2 are each very
> big .EXEs (approx. 9 MB each, 3.5 MB UPX'd). I don't know if that's
> really more useful than the existing two older MuPDF viewers we have,
> nor if somehow better than XPDF or Ghostscript converters.

For good or bad (probably good), the MuPDF developers seem to explicitly link statically, even on Windows, for MuPDF. Ironically, this is one of the few times where I think dynamic linking could possibly be useful, even for DJGPP, but it's really only (to my mind) to avoid having two bloated .EXEs using the same guts. (I guess a symlink acting appropriately upon argv[0] wouldn't be the worst compromise, but for whatever reason, that's rarely done.)

>
> (Fri Apr 26, 07:43 PM) /tmp/doydoy # upx -qql /mnt/sda3/TEMP/*.exe
> 8922407 ->   3307752   37.07%   djgpp2/coff   /mnt/sda3/TEMP/mudraw.exe
> 8785024 ->   3256728   37.07%   djgpp2/coff   /mnt/sda3/TEMP/mutool.exe
>

>
> Though if anyone really wants, I will upload MUTOOL.EXE and MUDRAW.EXE for
> them somewhere.

Thanks to popular demand (not), I went ahead and packed and uploaded it to iBiblio anyways, in case anyone is ever interested. (Maybe only if you need virtual memory of CWSDPMI in tight RAM situations??)


http://ftp.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/mupdf/

mu_tl_dw.7z     2013-Apr-28 04:09:17    6.3M    application/octet-stream
mupdf12s.7z     2013-Apr-28 04:05:43    6.6M    application/octet-stream
no_view.txt     2013-Apr-28 04:28:35    1.2K    text/plain


N.B. Only using a 16 MB LZMA dictionary, so that should be small enough RAM footprint to not unduly burden anyone also without forcing a one-size-fits-all 20 MB download on anyone.

DOS386(R)

28.04.2013, 15:50

@ Rugxulo
 

MuPDF 1.2 (2013-02-27) ||| MUTOOL

> which is renaming to "mutool" instead of "mubusy"

MOOH :-)

> Yes, default mutool and mudraw Win32 binaries seem to (upon very
> light testing) still work under HX, but the others don't

most notably ???

> I'm honestly not sure how useful it is for us

very much

> (compared to older Ghostscript or XPDF)

XPDF can't brew pixel images from PDF ;-)

> MUDRAW can convert to .PNG, but I'm not sure of the best viewer for that
> (QPNG? Pictview?

Right :-)

> Or just use some converter (Image Magick?) for different format

Why ??? What's broken with PNG ?

> 3). It seems like Ghostscript and MuPDF are somehow connected

AFAIK MuPDF is based on Ghostscript ...

> Also the various licensing changes over the years are confusing

What did change ??? You don't have to bother if you don't run modified MOOH on a public server ;-)

> Not sure what's different in GNU Ghostscript, but clearly (as has been
> mentioned before) none of these directly support DOS anymore (or at
> least not VESA drivers

Did it ever support them ???

> Though if anyone really wants, I will upload MUTOOL.EXE and MUDRAW.EXE
> http://ftp.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/mupdf/

Thanks, I'll test :-)

> you want smaller .EXEs, try "upx --best --lzma --hyper-brute" (avoided here
> because it would've hurt compression across both files, which both use the same

You got it :-)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Rugxulo(R)

Homepage

Usono,
01.05.2013, 15:16

@ DOS386
 

MuPDF 1.2 (2013-02-27) -- MUTOOL + MUDRAW

> > Yes, default mutool and mudraw Win32 binaries seem to (upon very
> > light testing) still work under HX, but the others don't
>
> most notably ???

I don't understand. It's been mentioned that the GUI viewers can't (or at least don't) work under HX. So your only luck is using MUTOOL or MUDRAW.

> > I'm honestly not sure how useful it is for us
>
> very much

I'm not PNG obsessed like you, but apparently they aren't compressed as optimally after writing. "advpng -z4 *.png" works. Then again, unlikely to distribute those when the actual PDF (or, even better, plain text) is smaller.

My .ZIP of P5 Pascal would shrink in half (4.8 MB to 2.3 MB) if I removed the bloated ISO7185.PDF file. (I'm not sure what advantages the pages-as-scanned-images PDF version has over the included .html conversion. IIRC there are no graphics and barely any fonts or fancy text. In other words, probably useless, but oh well. Even using "ps2pdf" via gs 8.71 on the .ps [made with TeX/WEB/Pascal] from elsewhere is 1/10th of the size [400 kb vs. 4000 kb]. So meh.)

> > (compared to older Ghostscript or XPDF)
>
> XPDF can't brew pixel images from PDF ;-)

Didn't it optionally have PDFTOPPM? But we (I?) didn't compile that due to needing FreeType. It might work, dunno. Not exactly curious to find out right now.

> > MUDRAW can convert to .PNG, but I'm not sure of the best viewer for that
> > (QPNG? Pictview?
>
> Right :-)

Which? I even had trouble with DuglView not working for me. (Maybe Intel gfx bugs of this computer, hi Laaca!) Having a tiny thumbnail preview is nice (QPV, DISPLAY), but it's not crucial (and sadly those aren't open source). (Workaround: convert .PNG or .JPG to .BMP or .GIF and use XPL0's TH.EXE.)

> > Or just use some converter (Image Magick?) for different format
>
> Why ??? What's broken with PNG ?

Name one 16-bit PNG viewer. I can't think of any. So you're stuck converting the format to .BMP (or similar). There are hundreds of (old) viewers for DOS, and most of them don't support .PNG. I have nothing against .PNG, but it's certainly less common (at least regarding legacy software) than GIF, BMP, PCX, JPG, etc.

I'm really no license purist, far from it. But sometimes even I gotta say, "Yeah, sources would be better."

In particular, I know image viewers try to choose the biggest, most color-appropriate mode for each image, but it's annoying when this particular desktop (monitor? low-end integrated gfx?) takes like three seconds to changes modes for every file. It really doesn't need to change mode between "pages" using the same resolution and colors. Also, I think panning is unavoidable on larger images unless you're lucky enough to have a monitor / card that supports everything. (Apparently mine doesn't like 1280 x whatever. Even you complained about that recently, IIRC.)

> > 3). It seems like Ghostscript and MuPDF are somehow connected
>
> AFAIK MuPDF is based on Ghostscript ...

Or using the same rendering engine or maybe fitz is a rewrite of the graphics lib backend, dunno.

> > Also the various licensing changes over the years are confusing
>
> What did change ??? You don't have to bother if you don't run modified MOOH
> on a public server ;-)

Still, I'm so apathetic to licensing, it's almost always pointless.

> > Not sure what's different in GNU Ghostscript, but clearly (as has been
> > mentioned before) none of these directly support DOS anymore (or at
> > least not VESA drivers
>
> Did it ever support them ???

Officially? Dunno, but there is (IIRC) at least one DOS "port" with VESA support. Maybe Mik added it, dunno.

> > you want smaller .EXEs, try "upx --best --lzma --hyper-brute" (avoided
> here
> > because it would've hurt compression across both files, which both use
> the same
>
> You got it :-)

BTW, now I'm frustrated because I think I compressed the .EXEs incorrectly. I thought I was saving RAM, but I think even dictionary size isn't everything (and -ms=16m certainly is bad for 18 MB of .EXE, ugh). So my ideal that it would "mostly" (and painlessly) extract in 16 MB in DOS is probably not realistic.

My old mu_tl_dw.7z is 6.5 MB while I can compress a newer one via "7za a -mx9 -md=16m new mutool.exe mudraw.exe" to only 3.5 MB. Both still seem to need approx. 21 MB of DPMI (eg. "dpmi -m 0x5000") under DOSEMU for "7za t". So whatever I thought I was accomplishing, it didn't work (and just bloated up the main .7z).

I guess I'll refresh the .7z on iBiblio with the smaller one. (Same build just different compression. Repack it yourself if you don't want to download again.) Done.

Rugxulo(R)

Homepage

Usono,
06.05.2013, 18:23

@ Rugxulo
 

MuPDF 1.2 (2013-02-27) -- MUTOOL + MUDRAW

> My .ZIP of
> P5
> Pascal would shrink in half (4.8 MB to 2.3 MB) if I removed the
> bloated ISO7185.PDF file. (I'm not sure what advantages the
> pages-as-scanned-images PDF version has over the included .html conversion.
> IIRC there are no graphics and barely any fonts or fancy text. In other
> words, probably useless, but oh well. Even using "ps2pdf" via gs 8.71 on
> the .ps [made with TeX/WEB/Pascal] from elsewhere is 1/10th of the size
> [400 kb vs. 4000 kb]. So meh.)

Apparently it was run through some OCR program (OmniPage Pro?) in order to have embeddable, selectable text.

> I even had trouble with DuglView not working for me.

Apparently it doesn't like running from G:\ RAM disk, but it works okay atop C:\ hard drive.

> In particular, I know image viewers try to choose the biggest, most
> color-appropriate mode for each image, but it's annoying when this
> particular desktop (monitor? low-end integrated gfx?) takes like three
> seconds to changes modes for every file. It really doesn't need to change
> mode between "pages" using the same resolution and colors.

Dugl Viewer supports this (no mode changes), though I can't remember if it's default or has to be tweaked in config file.

> My old mu_tl_dw.7z is 6.5 MB while I can compress a newer one via "7za a
> -mx9 -md=16m new mutool.exe mudraw.exe" to only 3.5 MB. Both still seem to
> need approx. 21 MB of DPMI (eg. "dpmi -m 0x5000") under DOSEMU for "7za t".
> So whatever I thought I was accomplishing, it didn't work (and just bloated
> up the main .7z).

I also later tried XZ Utils, out of curiosity, but apparently its --memlimit intentionally doesn't actually work these days (though at least verbose tells you approx. how much RAM will be needed to decompress). Meh.

DOS386(R)

23.05.2013, 11:20

@ Rugxulo
 

MuPDF 1.2 (2013-02-27) -- MUTOOL + MUDRAW | scan crap

> I don't understand. It's been mentioned that the GUI viewers can't (or at
> least don't) work under HX. So your only luck is using MUTOOL or MUDRAW

seems to work ...


usage: mutool <command> [options]
        clean   -- rewrite pdf file
        extract -- extract font and image resources
        info    -- show information about pdf resources
        poster  -- split large page into many tiles
        show    -- show internal pdf objects


... except "poster" ???

> I'm not PNG obsessed like you, but apparently they aren't compressed as
> optimally after writing

NOT a big problem ;-)

> My .ZIP of P5 would shrink in half (4.8 MB to 2.3 MB) if I removed the
> bloated ISO7185.PDF file. (I'm not sure what advantages the
> pages-as-scanned-images PDF version has over the included .html conversion.
> IIRC there are no graphics and barely any fonts or fancy text. In other
> words, probably useless

Kick it :-)

> Apparently it was run through some OCR program (OmniPage Pro?)

BTW, the "ISO7185.PDF" file is NOT scanned ... the pixel images are generated and the HTML explains (partially) the OCR story :-)

The "PAS1973.PDF" is scanned.

> Didn't it optionally have PDFTOPPM? But we (I?) didn't compile that due to
> needing FreeType. It might work, dunno

IIRC the XPDF DGJPP packages never had a PDFTOPPM binary long ago when the author provided them at all ... and the Win32 binary doesn't work with HX (RTFW) :hungry:

> Name one 16-bit PNG viewer

You mean 16 bppc PNG (so 16 or 48 or 64 bits total) ? Untested.

Or a DPMI-free PNG viewer ? PictView.

Or a 8086 compatible one ? :-( (but no 8086 PDF tool either)

> There are hundreds of (old) viewers for DOS, and most
> of them don't support .PNG.

Get a bigger recycle bin :-)

> have nothing against .PNG, but it's certainly less common (at least
> regarding legacy software) than GIF, BMP, PCX, JPG, etc

This is not an argument against PNG :-)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386(R)

06.07.2016, 10:24
(edited by DOS386, 06.07.2016, 10:53)

@ DOS386
 

XPDF 3.04 released 2014-May-28

XPDF 3.04 released 2014-May-28 ... sorry for old news and bumping an old thread ... testing XPDF 3.04 just now ...

* still seems to work with HX and P3 processor
* added PDFTOPNG tool (equally useless as previous PDFTOPPM) ... still using PDFDRAW from MU 0.9
* added PDFTOHTML tool (untested)

http://www.foolabs.com/xpdf/download.html

> # Apollo 425e, DomainOS 10.4.1.2 (xpdf 0.5)
> # m68k (HP-9000/425), HP-UX 9.0 (xpdf 0.5)
> # Alpha, Linux (xpdf 0.7)

DOS completely deleted from page :-(

PS: MU is at version 1.9 (untested) ... but old versions are available again:

http://mupdf.com/downloads/archive

PPSS: the RTFW link posted in several PDF threads here doesn't work anymore. Here the new one: RTFW

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386(R)

08.07.2016, 08:10

@ DOS386
 

XPDF 3.04 released 2014-May-28 (tests)

> * still seems to work with HX and P3 processor

it (XPDF 3.04) works even on P1 :-)

> * added PDFTOHTML tool (untested)

it works with HX ... brews junk complaints about fonts but produces somewhat valid result ... 1 HTML and 1 PNG as "background" for every page ... unfortunately no DOS browser can display this type HTML ... on Fire-Fox layout and text styles are OK, but fonts too small

now this one is finally totally obsolete and useless

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Back to index page
Thread view  Board view
15115 Postings in 1359 Threads, 249 registered users, 11 users online (0 registered, 11 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum