DOS ain't dead

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.

> 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.

> 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) {