DOS ain't dead

Im using win95 for PDF..

I checked long time ago pdf readers for DOS, but they require a lot of tools and conversions to read a PDF.

Exist any simple PDF reader, or this is a hard task for DOS?

> Im using win95 for PDF



> I checked long time ago pdf readers for DOS, but they require a
> lot of tools and conversions to read a PDF



> Exist any simple PDF reader, or this is a hard task for DOS?

Hard task. Get XPDF.

PS: please drop further requests into Users rather than Announce.

PPSS: FYI: ACRO 1.0 for DOS/DOG is useless (was a 32-bit DOS app). ACRO 2.0 degraded to Win16

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

> PPSS: FYI: ACRO 1.0 for DOS/DOG is useless (was a 32-bit DOS app).

Why? I sometimes use it.

---
DOS-u-akbar!

> > PPSS: FYI: ACRO 1.0 for DOS/DOG is useless (was a 32-bit DOS app).
>
> Why? I sometimes use it.

Simply because now most PDF you download are newer format. I even have problem with Acrobat 6.0 (last for Win9x) that it cannot read new files. So I replaced it with Foxit reader.

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

> Simply because now most PDF you download are newer format. I even have
> problem with Acrobat 6.0 (last for Win9x) that it cannot read new files. So
> I replaced it with Foxit reader.

Ok I haven't tried the following (nor do I have the time right now) and I also appreciate that this won't answer this request fully, however it is an idea:

I wondered if anyone has tried the GPL'd Windows command-line port of Pdftk with Japheth's HX-DOS Extender?

The Windows Pdftk binary (1 EXE + 1 DLL) can be downloaded from:
http://www.pdflabs.com/docs/install-pdftk/

> Im using win95 for PDF..
>
> I checked long time ago pdf readers for DOS, but they require a lot of
> tools and conversions to read a PDF.
>
> Exist any simple PDF reader, or this is a hard task for DOS?

Xpdf gets the text from a pdf.

I prefer to see each page in full colour, graphics and printable.
So I use Arachne with the Ghostscript plug-in. Both local and remote files.
Once set up, it appears seamless. One click !

Laaca wrote:

> > PPSS: FYI: ACRO 1.0 for DOS/DOG is useless (was a 32-bit DOS app).
> Why? I sometimes use it.

Then your documents are 20 years old. AFAIK it accepts PDF 1.0 well, PDF 1.1 usually well, PDF 1.2 usually badly or not at all, and anything newer definitely not at all.

> I prefer to see each page in full colour, graphics and printable.
> So I use Arachne with the Ghostscript plug-in.

Link ?

PS: Any reccommandations about standalone GhostScript binary (and how to use) ?

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

> > I prefer to see each page in full colour, graphics and printable.
> > So I use Arachne with the Ghostscript plug-in.
>
> Link ?

http://www.glennmcc.org/apm/

Look for ara-pdf.apm, where there is also a link to ghostscript.
You will need both.


> PS: Any reccommandations about standalone GhostScript binary (and how to
> use) ?

There is a way to do it with ghostscript alone, I managed it once.
But the documentation is so confusing that I prefer to use the Arachne route.

> I wondered if anyone has tried the GPL'd Windows command-line port of
> Pdftk with Japheth's
> HX-DOS Extender?
>
> The Windows Pdftk binary (1 EXE + 1 DLL) can be downloaded from:
> http://www.pdflabs.com/docs/install-pdftk/

I just tried PDFTK in pure DOS with HX. Gave the following
errors:

dpmild32: import not found: GetHandleInformation
dpmild32: file KERNEL32.dll
dpmild32: C:\WINDOWS\SYSTEM\msvcrt.dll: cannot resolve imports

My PATH includes C:\Windows\System, and DOSLFNMS was installed
(otherwise, LIBICONV2.DLL won't load).

-----------------------------------------------------------------
Interestingly, i recently stumbled across another lightweight PDF
viewer/toolkit for Windows 32 -- MUPDF -- which i also tried out
in pure DOS with HX. It's written by Artifex, the good folks
who bring us GPL Ghostscript:

http://mupdf.com

It didn't work either, but the errors *seemed* minimal (not
really being much of a programmer and not really being too
knowledgeable about HX):

Viewer (GUI - MUPDF.EXE):

dpmild32: import not found: IsProcessorFeaturePresent
dpmild32: file KERNEL32.dll
dpmild32: d:\hx\vesa32.dll: cannot resolve imports

Tools (TUI - PDFCLEAN.EXE, PDFDRAW.EXE, PDFSHOW.EXE):

dpmild32: import not found: IsProcessorFeaturePresent
dpmild32: file KERNEL32.dll
dpmild32: D:\HX\dkrnl32.dll: cannot resolve imports

(I have the HX/HXGUI binares installed in D:\HX\ directory.)

So maybe that's another avenue to explore. It's GPL, so the
source is available. Wondering could it be hacked to work under
HX? (Beyond my abilities.)

Wouldn't it be cool to have an up-to-date PDF viewer for DOS?

- Doug B.

>
> PS: please drop further requests into Users rather than
> Announce.

oh sorry.. I found this forum with link directly to "Announce" subcategory... I didn t imagine that forum was bigger


Ill revise main forum and post further threads in the correct section ;)

> It didn't work either, but the errors *seemed* minimal (not
> really being much of a programmer and not really being too
> knowledgeable about HX):
>
> Viewer (GUI - MUPDF.EXE):
>
> dpmild32: import not found: IsProcessorFeaturePresent
> dpmild32: file KERNEL32.dll
> dpmild32: d:\hx\vesa32.dll: cannot resolve imports
>
> Tools (TUI - PDFCLEAN.EXE, PDFDRAW.EXE, PDFSHOW.EXE):
>
> dpmild32: import not found: IsProcessorFeaturePresent
> dpmild32: file KERNEL32.dll
> dpmild32: D:\HX\dkrnl32.dll: cannot resolve imports
>
> (I have the HX/HXGUI binares installed in D:\HX\ directory.)
>
> So maybe that's another avenue to explore. It's GPL, so the
> source is available. Wondering could it be hacked to work under
> HX? (Beyond my abilities.)

Had only a quick look: The executables are looking for PF_XMMI64_INSTRUCTIONS_AVAILABLE (the SSE2 instruction set).

Also MuPDF-based: http://blog.kowalczyk.info/software/sumatrapdf/

---
Forum admin

> > Viewer (GUI - MUPDF.EXE):
> >
> > dpmild32: import not found: IsProcessorFeaturePresent
> > dpmild32: file KERNEL32.dll
> > dpmild32: d:\hx\vesa32.dll: cannot resolve imports
> >
> > Tools (TUI - PDFCLEAN.EXE, PDFDRAW.EXE, PDFSHOW.EXE):
> >
> > dpmild32: import not found: IsProcessorFeaturePresent
> > dpmild32: file KERNEL32.dll
> > dpmild32: D:\HX\dkrnl32.dll: cannot resolve imports

Hey, I cannot run MUPDF.EXE

dpmild32: import not found: GetOpenFileNameW
dpmild32: file COMDLG32.dll
dpmild32: c:\dos\win32\COMDLG32.dll: cannot resolve imports

but I can run PDFDRAW.EXE and export the pages in png and view them by image viewer. I think it may be possible to recompile tools with djgpp and modify mupdf or pdfdraw to render images though vesa routines...

SumatraPDF doesn't run too. But I can run it under Win98SE+kernelEx. It's smallest windows PDF viewer I ever seen :)

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

I'm trying to recompile MuPDF under DJGPP, so first started with libraries, I have done 4/5 but ended with OPENJPEG, it failed very soon :\
(there's no cczHgSkN.s in tempdir, resp. it's immediately deleted :P)

L:\mupdf_07\SOURCE\LIBS\OPENJPEG>make
gcc -Wall -O3 -ffast-math -std=c99 -fPIC -Ilibopenjpeg -c libopenjpeg/bio.c -o l
ibopenjpeg/bio.o
L:\WINXP\TEMP/cczHgSkN.s: Assembler messages:
L:\WINXP\TEMP/cczHgSkN.s:15: Error: junk `@PLT' after expression
L:\WINXP\TEMP/cczHgSkN.s:35: Error: junk `@PLT' after expression
make.exe: *** [libopenjpeg/bio.o] Error 1


UPDATE: caused by -fPIC gcc option - not supported in DJGPP?

UPDATE2: libs done but got:

In file included from fitz/filt_jbig2d.c:15:0:
e:/djgpp/include/inttypes.h:190:3: error: expected specifier-qualifier-list before 'intmax_t'
e:/djgpp/include/inttypes.h:194:10: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'imaxabs'
e:/djgpp/include/inttypes.h:195:29: error: expected ')' before '_numer'
e:/djgpp/include/inttypes.h:196:10: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'strtoimax'
e:/djgpp/include/inttypes.h:197:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'strtoumax'

Maybe need update of INTTYPES.H, year 2003

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

> Viewer (GUI - MUPDF.EXE):
> dpmild32: import not found: IsProcessorFeaturePresent
> dpmild32: file KERNEL32.dll
> dpmild32: d:\hx\vesa32.dll: cannot resolve imports

Good, I patched away this problem ... and it crashes at address $15 :xxxx:

> Also MuPDF-based: "blog.kowalczyk.info/software/sumatrapdf"

Right ... much more higl level GUI API, no use for DOS

> Hey, I cannot run MUPDF.EXE
> dpmild32: import not found: GetOpenFileNameW
> but I can run PDFDRAW.EXE and

Some private HX fork ?

> export the pages in png and view them by image viewer.

COOL

> I think it may be possible to recompile tools with djgpp and modify
> mupdf or pdfdraw to render images though vesa routines...

COOL

> SumatraPDF doesn't run too.

Unsurprisingly, see above.

> It's smallest windows PDF viewer I ever seen

Right ... anyone knows what (bloat) MU has what Suma hasn't ?

> I'm trying to recompile MuPDF under DJGPP, so first started with libraries

COOL

BTW, I tested XPDF too, there are Win32 binaries and DGJPP binaries,
and the DGJPP binaries lack "pdftoppm.exe". Why? Font handling isn't
native, the Win32 version outsources the work to the Win32 font API.
So in HX it runs very well, just the result is "Font Blah-Bold not found"
1'000'000'000'000 times and almost empty pages saved

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

> Some private HX fork ?

No, I have installed complete HXDOS 2.16 and set path to my win98se directory

> Right ... anyone knows what (bloat) MU has what Suma hasn't ?

It probably depends on built in fonts.

I need to solve the mess with djgpp headers first. I have installed latest gcc 4.5.2 but mentioned headers are not part of the package. I don't know which - djdev204? There may be some cvs updates to djdev but where is some working (tested binary) version?

I have also problems with headers that contains "#include_next" I had to comment it.

e:/djgpp/include/stdint.h:3:26: error: no include path in which to search for st
dint.h

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

Yipy yeee!
I finally fixed my broken system headers (I hadn't luck with include_next so I renamed original conflicting djdev headers to *dj.h and then replaced include_next *.h to include *dj.h) and finally was able to compile the MuPDF package. Of course there's no mupdf.exe itself coz it depends on win32 stuff but pdfdraw.exe works fine, go ahed to test it!

http://www.ulozto.cz/7940392/mupdf-07-djgpp-rar
(click "stahnout" and then enter captcha)

(sources and all libs inluded, modified to compile libs separately)

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

>> Viewer (GUI - MUPDF.EXE):
>>
>> dpmild32: import not found: IsProcessorFeaturePresent
>> dpmild32: file KERNEL32.dll
>> dpmild32: d:\hx\vesa32.dll: cannot resolve imports
>>
>> Tools (TUI - PDFCLEAN.EXE, PDFDRAW.EXE, PDFSHOW.EXE):
>>
>> dpmild32: import not found: IsProcessorFeaturePresent
>> dpmild32: file KERNEL32.dll
>> dpmild32: D:\HX\dkrnl32.dll: cannot resolve imports
>
> Hey, I cannot run MUPDF.EXE
>
> dpmild32: import not found: GetOpenFileNameW
> dpmild32: file COMDLG32.dll
> dpmild32: c:\dos\win32\COMDLG32.dll: cannot resolve imports
>
> but I can run PDFDRAW.EXE and export the pages in png and view them by
> image viewer.

RayeR -

Hey. Interesting that:

1) You got the Win32 PDFDraw to work in pure DOS with HX. (I
just tried again -- no go for me, same error messages as
before.)

2) You got different dependency errors than i did for MUPDF.EXE.

I'm curious how this could be. My other HX-friendly Win32
programs seem to be working ok, but now i'm second-guessing
myself -- maybe there are some that *should* be working but
aren't.

My HX binaries directory is before C:\Windows\System (which is
the last entry) in my PATH. HXLDR32 is resident (installed from
CONFIG.SYS). No other DPMI is resident nor EMM manager (i'm
using UMBPCI instead). This is HX version 2.17 (DUSER32.DLL from
06-03-2010) with MS-DOS 7.1.

Just curious.... anyone.

- Doug B.

And here is the first beta of graphical mupdf viewer for DOS :)
tune crtc.cfg for best performance/compatability
It should work also in VGA mode 13h if VESA VBE not found

http://rayer.ic.cz/350d/mupdf_07_dos.zip

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

> Yipy yeee!
> I finally fixed my broken system headers (I hadn't luck with include_next
> so I renamed original conflicting djdev headers to *dj.h and then replaced
> include_next *.h to include *dj.h) and finally was able to compile the
> MuPDF package. Of course there's no mupdf.exe itself coz it depends on
> win32 stuff but pdfdraw.exe works fine, go ahed to test it!
>
> http://www.ulozto.cz/7940392/mupdf-07-djgpp-rar
> (click "stahnout" and then enter captcha)
>
> (sources and all libs inluded, modified to compile libs separately)

Just saw the message about the graphical MuPDF -- so maybe this
note is moot. Nevertheless, i already typed it out, so here it
is anyway....

---
Ok, i've dome some preliminary work with RayeR's DGJPP PDFDraw.
It took every PDF i threw at it, and i'm impressed with it's
speed. Very nice (and quick!) work, RayeR!

I've caught a few (of those Unix-inspired) "gotcha's" in the
program (tested under 4DOS 8.0 and MS-DOS COMMAND.COM 7.1):

Options are case sensitive, as you will notice when you do the -?
help request.

However, the filename extension for the "-o" (output file) option
is *also* case-sensitive: it must be lower-case for the
png/pam/ppm/pgm specification or else nothing gets written to
disk! (Being an original PC-DOS head, stuff like this drives me
nuts! I don't realize it for awhile, and wonder why the program
doesn't work. Particularly in batch files, i like to use
capitalization to make things clearer.)

Also, with multiple-page PDF files, each succeeding output image
file will overwrite the previous, leaving only the final one on
disk. To keep them all, you need to use the %d variable in the
output-filename specification. So, for example, to save all
pages from a multi-page .PDF, you need to do something like:

pdfdraw -o out%d.png origfile.pdf

But, %d (as is) doesn't seem to work in 4DOS. You need to double
the % sign with 4DOS, as in:

pdfdraw -o out%%d.png origfile.pdf

(To reiterate, the single %d works ok with COMMAND.COM. But...
does anybody even use COMMAND.COM anymore?)

Anyway, these are just minor issues -- it's totally great to have
an up-to-date and quick way to display PDFs... in DOS... in the
year 2011! Who'd a thunk it....

- Doug B.

P.S. "Quick" meaning quicker than XPDF+Ghostscript -- making a
.PS from a .PDF using PDFTOPS (XPDF), then making an image file
from the .PS using Ghostscript, and finally displaying the image
file. Even with a batch file... slow... creaky....

> http://www.ulozto.cz/7940392/mupdf-07-djgpp-rar

Nope

> http://rayer.ic.cz/350d/mupdf_07_dos.zip

Downloads works (but no source in).

> And here is the first beta of graphical mupdf viewer for DOS
> tune crtc.cfg for best performance/compatability
> It should work also in VGA mode 13h if VESA VBE not found

COOL

> [800 600]

OK

> 1376 1024 1088 1200 '-' NI
> 807 768 769 772 '+'
> 94.39
> # end of GTFCALC configuration data
> # set calculated CRTC data for current videomode, for calc. run GTFCALC program
> [0/1]
> set_crtc = 0

I don't understand

> # bits per pixel [8/15/16/24/32]
> bpp = 32

OK, I need 24 at most

> # use Linear Frame Buffer mode if available (on VESA VBE 2.0+ adapters)
> [0/1], set 0 if run under Windows NT
> use_lfb = 0

I'll try 1 of course

> # use MTRR Write-Combining memory mode for LFB/BS window on P6+ systems > [0/1]
> use_mtrr_wc = 0
> # use vertical synchronization [0/1]
> use_vsync = 1

OK ...

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

> And here is the first beta of graphical mupdf viewer for DOS :)
> tune crtc.cfg for best performance/compatability
> It should work also in VGA mode 13h if VESA VBE not found
>
> http://rayer.ic.cz/350d/mupdf_07_dos.zip

Thanks! It seems to work great with the pdf files I have, excepting Google-Digitized Books pdfs (the program freezes without displaying anything), perhaps because those have pages of different resolutions.

---
Glory to God for all things

> Thanks! It seems to work great with the pdf files I have, excepting
> Google-Digitized Books pdfs (the program freezes without displaying
> anything), perhaps because those have pages of different resolutions.

Please upload such one pdf that I can test it. The MuPDF renderer can produce image in various color formats and I tested only plain 32bit BGRA.

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

I think I can modify the case sensitivity of args. I also don't like it.

> pdfdraw -o out%d.png origfile.pdf
>
> But, %d (as is) doesn't seem to work in 4DOS. You need to double
> the % sign with 4DOS, as in:
>
> pdfdraw -o out%%d.png origfile.pdf

I run into same problem, I didn't know about double %%.

> (To reiterate, the single %d works ok with COMMAND.COM. But...
> does anybody even use COMMAND.COM anymore?)

I do (original MS-DOS 6.22 - as a reference for compatability)

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

> > Thanks! It seems to work great with the pdf files I have, excepting
> > Google-Digitized Books pdfs (the program freezes without displaying
> > anything), perhaps because those have pages of different resolutions.
>
> Please upload such one pdf that I can test it. The MuPDF renderer can
> produce image in various color formats and I tested only plain 32bit BGRA.

You may try any of these. I think that the problem is related to pages having different resolutions (i.e. sizes), it works with all the pdfs I tried having all the pages with the same resolution.

---
Glory to God for all things

> Downloads works (but no source in).

I have to do some code clean up 1st and convert cz comment to eng. But I release code only for dos_main.c not the vesa library, it's still under devel. and not ready.

> > 1376 1024 1088 1200 '-' NI
> > 807 768 769 772 '+'
> > 94.39
> > # end of GTFCALC configuration data
> > # set calculated CRTC data for current videomode, for calc. run GTFCALC
> program
> > [0/1]
> > set_crtc = 0
>
> I don't understand

This is CRTC register timings to set refreshrate. Probably as a human you cannot suck this numbers from a thumb but you can use GTFCALC utility where you enter resolution and refresh rate and it will thow a file with such timings :) I will include it in next release. But if you have a poor CRT don't play with it :)

> OK, I need 24 at most

you can leave 32 here it will detect if your card have 24 or 32bpp modes

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

> You may try any of
> these.

I tried 1st book on page, where's the download link to PDF? If I click PDF (3,3M) link it takes me here
http://books.google.com/books?id=EgcAAAAAYAAJ&oe=UTF-8 I don't see...

Aha I had to click "All Files: HTTP" got it.

> I think that the problem is related to pages having different resolutions
> (i.e. sizes), it works with all the pdfs I tried having all the
> pages with the same resolution.

BTW did you tried pdfdraw if export to png works?

EDIT: The bug is somewhere deeper, even pdfdraw CRASHES:
(Win32 binary (supplied) works)

Exiting due to signal SIGILL
Invalid Opcode at eip=000419a0
eax=007684d0 ebx=00000001 ecx=0060a74f edx=0080e4e8 esi=000419a0 edi=0060a74f
ebp=007686e8 esp=0076849c program=L:\MUPDF.07\PDFDRAW.EXE
cs: sel=01a7  base=029f0000  limit=0086ffff
ds: sel=01af  base=029f0000  limit=0086ffff
es: sel=01af  base=029f0000  limit=0086ffff
fs: sel=017f  base=000066d0  limit=0000ffff
gs: sel=01bf  base=00000000  limit=0010ffff
ss: sel=01af  base=029f0000  limit=0086ffff
App stack: [0076af88..006eaf88]  Exceptn stack: [006eaea8..006e8f68]

Call frame traceback EIPs:
  0x000419a0
  0x0060ab68
  0x00601bde
  0x006033c7
  0x
L:\MUPDF.07>


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

Hey!!! this pdfreader is working!!!God job pal!!

Here some questions and comments:

- I testing Vs foxitreader (win95) and foxit scroll down the images faster than mupdf :( . I was testing options in the CFG file.. but nothing improves the speed.
I hope more tweaks into the program will boost the image viewing speed

-when you press the right arrow to load the next page.. the image is displayed at same position than previous one loaded. For example if you scroll down to read the end of a page and you press right arrow.. the next page is loaded and it shows the bottom of the page.

- There is a key or option into the cfg file to load the images to fit screen weight?

Its a test.. but Im amazed with the results!!! Keep the work pal!

> - I testing Vs foxitreader (win95) and foxit scroll down the images faster
> than mupdf :( . I was testing options in the CFG file.. but nothing
> improves the speed.
> I hope more tweaks into the program will boost the image viewing speed

Under pure DOS enable LFB and MTRR and use 32bpp depth if you have such VESA mode. When program exit it display last frame render time it can give you idea if changed setting led to change in performance. With LFB and set MTTRs I got ~20ms in 1600x1200/32bpp. But don't expect the same speed as your windows use HW 2D acceleration. I simply redraw entire screen everytime you scroll (+-10 pixels).

> -when you press the right arrow to load the next page.. the image is
> displayed at same position than previous one loaded. For example if you
> scroll down to read the end of a page and you press right arrow.. the next
> page is loaded and it shows the bottom of the page.

I know, it need to fix Y-offset when zoom or goto another page. Will be fixed.

> - There is a key or option into the cfg file to load the images to fit
> screen weight?

No on first load I must specify some DPI but I don't know anything about image yet. When 1st page loads I can read image resolution and then adjust DPI for best fit. Yes I can do this calculation before start drawing on screen, see next update...

BTW there's short help if you press F1

> Its a test.. but Im amazed with the results!!! Keep the work pal!

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

> Under pure DOS enable LFB and MTRR and use 32bpp depth if you have such
> VESA mode. When program exit it display last frame render time it can give
> you idea if changed setting led to change in performance. With LFB and set
> MTTRs I got ~20ms in 1600x1200/32bpp. But don't expect the same speed as
> your windows use HW 2D acceleration. I simply redraw entire screen
> everytime you scroll (+-10 pixels).

I cannt go lower 227ms using these settings.. maybe my pentium166mmx is not enough ;/

Wow! I tried MuPDF and this is absolutely perfect! Thank you, RayeR.

...and it seems you have some interesting graphics library going behind usual VESA standard?

---
DOS-u-akbar!

> And here is the first beta of graphical mupdf viewer for DOS :)
> tune crtc.cfg for best performance/compatability
> It should work also in VGA mode 13h if VESA VBE not found
>
> http://rayer.ic.cz/350d/mupdf_07_dos.zip

Works very well for me thanks !
Maybe we can make another version of your reader using DUGL http://www.bttr-software.de/forum/forum_entry.php?id=9546
but it will be limited to only 16bpp

> > But, %d (as is) doesn't seem to work in 4DOS. You need to double
> > the % sign with 4DOS, as in:
> >
> > pdfdraw -o out%%d.png origfile.pdf
>
> I run into same problem, I didn't know about double %%.
>
> > (To reiterate, the single %d works ok with COMMAND.COM. But...
> > does anybody even use COMMAND.COM anymore?)
>
> I do (original MS-DOS 6.22 - as a reference for compatability)

IIRC, 4DOS accepts "%blah" as a shortcut to "%blah%". Also, keep in mind that normal .BATs need "%%" inside to represent "%" for syntax reasons. Try this:


@echo off
echo Hello %world
echo Hello %%world


EDIT: BTW, old MS-DOS 6.22's COMMAND.COM (unless I'm remembering incorrectly) doesn't accept %blah% on raw cmdline (outside of .BAT), but newer versions from Win9x do. At least FreeDOS' FreeCOM and 4DOS both do.

> And here is the first beta of graphical mupdf viewer for DOS :)
> tune crtc.cfg for best performance/compatability
> It should work also in VGA mode 13h if VESA VBE not found
>
> http://rayer.ic.cz/350d/mupdf_07_dos.zip

MuPDF.exe. It ran right out of the box -- i didn't need to tweak
CRT.CFG. (Intel 865G video chipset on m/b, VBE 3.0, tweaked with
VBEHz on bootup.)

Display/scroll speed is fine for me (2.8ghz P4), but i can see
how it could possibly be an issue on slower machines. I don't
think DOS can use video hardware acceleration.

F1 keypress displays a superimposed list of keyboard keys and
their functions. It fades in a few seconds without the need to
press another key.

The CRTC.CFG file has a comment line that sez: "set calculated
CRTC data for current videomode, for calc. run GTFCALC program".
"GTF" stands for "Generalized Timing Formula", a VESA standard
for CRT systems:

http://en.wikipedia.org/wiki/General_Timing_Formula

Unfortunately, the link on that page to a spreadsheet on the VESA
site that helps you calculate the params is broken. However, i
found a copy here:

www.cs.unc.edu/Research/stc/FAQs/Video/GTF_V1R1.xls

You must be messin' close to the hardware, eh?

So, wow. An up-to-date, self-contained PDF viewer for DOS.
Totally awesome. RayeR... you da MAN! (And that was a *really*
quick turnaround time.)

- Doug B.

Very impressive! A new and indispensible DOS application in 2011 that fills a real need! Kudos to you for keeping DOS alive and thriving...

This worked extremely well out of the box, on all of my systems. I even tweaked it to display PDFs in my netbook's native 1024x600 resolution (1:1 pixel mapping), but have yet to figure out the exact refresh rate timings, etc.

It has worked with every PDF I've thrown at it! What a piece of magic, and a gift for the DOS community.

The PDFCLEAN.EXE utility is wonderful. I found that a great way to archive .PDFs is to use the -ggg option combined with the -d (decompress) options and then recompress the .PDFs with 7zip (the excellent DOS port of 9.13). Saves hundreds of MBs with the much more efficient lzma compression over the default deflate algorithms used in PDFs.

YES it works, thanks



(deliberately reduced to 15 colors)



(deliberately reduced to 64 grey)

> http://www.uloz.to/7940392/mupdf-07-djgpp-rar

Clone of Rapid-SH** and Media-F***

Please put future releases on your page or here: http://ompldr.org/

> Maybe we can make another version of your reader using DUGL

MUPDF is GPL 3. So full source code of derivative works must be released. Or pay for the commercial license not having this requirement.

> you can use GTFCALC utility where

Where is it ?

> The PDFCLEAN.EXE utility is wonderful. I found that a great way to archive
> .PDFs is to use the -ggg option combined with the -d (decompress) options
> and then recompress the .PDFs with 7zip (the excellent DOS port of 9.13)

faulty port

> Saves hundreds of MBs with the much more efficient lzma compression
> over the default deflate algorithms used in PDFs.

Maybe LZW84 ???

It can take a long time to display the page (black screen) or react to ZOOM (old page) ... a progress indicator would be cool

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

> And here is the first beta of graphical mupdf viewer for DOS :)

Works! Thanks!

One thing I'm missing is the capability to change position to a page. The Windows version has a keyboard interface ("123g" positions to page 123), but this apparently doesn't work (yet?) in the DOS port.

---
MS-DOS forever!

http://rayer.ic.cz/350d/mupdf_07_dos.zip

New beta 0.2 to test
- args are case insensitive
- DPI is recalculated on startup so it should fit the screen (if you not override by -r ...)
- y_offset is reset when page # changed and zoomed
- go to page will be possible, it will require some input dialog or something interactive than just blind key combo...

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

> http://rayer.ic.cz/350d/mupdf_07_dos.zip
>
> New beta 0.2 to test
> - args are case insensitive
> - DPI is recalculated on startup so it should fit the screen (if you not
> override by -r ...)
> - y_offset is reset when page # changed and zoomed
> - go to page will be possible, it will require some input dialog or
> something interactive than just blind key combo...

Hey!! each time all working better.
Fit screen and Y-offset resets nice features.

I have request for you if possible.

I was testing this new version. The pages display full screen and if I move to next pages they load fast ( ok my p166mmx need arround 150ms), but the problem comes with laptops and small screens.

If I have a small screen.. I need to zoom-in because I cannt read the page properly (tiny words)... I notice mupdf resize at extra-quality.

request: could be posible add other resize mode options for low CPU users or people that need to render each image constantly cause they display the images zoomed-in and need to scroll down very often?

I dont know if you are using lanczos/spline resize because quality is amazing... can you try to add linear,bilinear, point resize or others?. If this option is available in the cfg file users can find their best balance between speed and image quality :)

> request: could be posible add other resize mode options for low CPU users
> or people that need to render each image constantly cause they display the
> images zoomed-in and need to scroll down very often?

I belive it could be possible but this would require go deep inside MuPDF sources. I have no idea how they inperpolate. I think it's done during rasterization of vector fonts and graphics so the rasterizer would need to be rewritten. Main application only tell target DPI and the engine will provide pointer to target bitmat that I simply draw (internal representation is 32bit truecolor BGRA so if you have 32bpp mode it is fitted 1:1 without any recalc. If you have 24/16/8bpp mode, recalculation is needed but also output data are smaller so less PCI bus load to fill the framebuffer...)

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

> 2) You got different dependency errors than i did for MUPDF.EXE.
>
> I'm curious how this could be. My other HX-friendly Win32
> programs seem to be working ok, but now i'm second-guessing
> myself -- maybe there are some that *should* be working but
> aren't.

And what windows do you have in path? I have Win98SE but I found that MuPDF/win32 event don't run there. Only with KernelEx ;)

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

> F1 keypress displays a superimposed list of keyboard keys and
> their functions. It fades in a few seconds without the need to
> press another key.

will be improved...

> The CRTC.CFG file has a comment line that sez: "set calculated
> CRTC data for current videomode, for calc. run GTFCALC program".
> "GTF" stands for "Generalized Timing Formula", a VESA standard
> for CRT systems:
>
> http://en.wikipedia.org/wiki/General_Timing_Formula
>
> Unfortunately, the link on that page to a spreadsheet on the VESA
> site that helps you calculate the params is broken. However, i
> found a copy here:
>
> www.cs.unc.edu/Research/stc/FAQs/Video/GTF_V1R1.xls
>
> You must be messin' close to the hardware, eh?

Yes, only DOS allows me to do without any obstacles :)
VESA defines GTF and they provided that demo XLS. But I rather used some Scitech (MGL)? source that contained a routine for calculating this. It's an old source I have to find it...

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

> > request: could be posible add other resize mode options for low CPU
> users
> > or people that need to render each image constantly cause they display
> the
> > images zoomed-in and need to scroll down very often?
>
> I belive it could be possible but this would require go deep inside MuPDF
> sources. I have no idea how they inperpolate. I think it's done during
> rasterization of vector fonts and graphics so the rasterizer would need to
> be rewritten. Main application only tell target DPI and the engine will
> provide pointer to target bitmat that I simply draw (internal
> representation is 32bit truecolor BGRA so if you have 32bpp mode it is
> fitted 1:1 without any recalc. If you have 24/16/8bpp mode, recalculation
> is needed but also output data are smaller so less PCI bus load to fill the
> framebuffer...)

Oh I understand.. change the interpolation mode have to be difficult. Each time I watch the rendered images of Mupdf I dont notice any aliasing... all the curves are perfectly smooth.. so I imagine that they are using a high quaility interpolation resize that requires extra cpu. The bpp really not affect so much to the speed.. almost similar speed at 32 or lower.

There is any other setting to change the quality of the output rendered image so maybe it can be generated/displayed faster?

> There is any other setting to change the quality of the output rendered
> image so maybe it can be generated/displayed faster?

I don't know yet, I'm busy with viewer, someone else may browse sources for it. I think there will be more places where the interpolation is solved, probably different for vectors, fonts and bitmaps. There are also some space to optimize used libs for decoding Jpegs, Z...

I tried to recompile MuPDF with some better optimizations, maybe help little bit
http://rayer.ic.cz/350d/mupdf_07_dos.zip
-O3 -DNDEBUG -fomit-frame-pointer -frerun-loop-opt -ffast-math -march=pentium-mmx
But I didn't rebuil all libs.
I also changed profiling debug output, you should see total render time and img blit time. I got very different numbers in 2 test case:
real PC: 25 / 24 ms (800x600/32bpp bankswitch (under XP))
DOSBox: 253 / 10 ms - so here you can see the effect of slow CPU but fast gfx.
So it would be interesting what is your ratio (low performance CPU vs low bandwith LFB transfer).
I have VESATEST log from one old Pentium 1 machine with old PCI VGA:

Generated by Martin's VGA13/VESA driver test 1.41
Host CPU id: 52Ch, host OS: DOS

VESA VBE 2.0 SiS super VGA chip. [4096 kB], SiS 6326

Probing VESA videomode 1024x768/24
VideoModeNumber = 4118h
2359296 kB allocated for FrameBuffer
LFB Selector = C7h
LFB PhysBasePtr = F0000000 h
Measured refresh rate = 87.39 Hz
Measured 19 FPS (FrameBuffer>VRAM)
(transfer speed 43 MB/s)

You can download and measure it here
http://rayer.ic.cz/350d/vesatest.exe

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

> I tried to recompile MuPDF with some better optimizations, maybe help
> little bit
> http://rayer.ic.cz/350d/mupdf_07_dos.zip
> -O3 -DNDEBUG -fomit-frame-pointer -frerun-loop-opt -ffast-math
> -march=pentium-mmx
> But I didn't rebuil all libs.
> I also changed profiling debug output, you should see total render time and
> img blit time. I got very different numbers in 2 test case:
> real PC: 25 / 24 ms (800x600/32bpp bankswitch (under XP))
> DOSBox: 253 / 10 ms - so here you can see the effect of slow CPU but fast
> gfx.

I was testing this new version and speed is almost the same
image in screen 340x480/4 152/14 ms

> So it would be interesting what is your ratio (low performance CPU vs low
> bandwith LFB transfer).

> Probing VESA videomode 1024x768/24
> VideoModeNumber = 4118h
> 2359296 kB allocated for FrameBuffer
> LFB Selector = C7h
> LFB PhysBasePtr = F0000000 h
> Measured refresh rate = 87.39 Hz
> Measured 19 FPS (FrameBuffer>VRAM)
> (transfer speed 43 MB/s)

VESA VBE 2.0 MagicGraph 128XD 40K SVGA BIOS [1984 kB]
probing 640x480/16
VideoModeNumber = 111h
614400 B allocated for FrameBuffer
WinFuncPtr = C000:1BF4h
WinGranularity = 64 kB
NumBanks = 9
LastSize = 24576 B
Measured refresh rate = 60.6 Hz
Measured 45 FPS (FrameBuffer>VRAM)
(transfer speed 26 MB/s)

I notice that I never enabled write combing under msdos.. Ill try with it... mayeb I gain some speed

> I was testing this new version and speed is almost the same
> image in screen 340x480/4 152/14 ms

So this mean the most time consuming is PDF processing, displaying page is only ~10% of time... I'm thinking now that maybe I do worthless PDF page render when scrolling! I cannot check source now but when I'll be back at home... For scrolling I need just adjust y_offset and redraw the sceen. If so, it could bring heavy speed up!

> VESA VBE 2.0 MagicGraph 128XD 40K SVGA BIOS [1984 kB]
> probing 640x480/16
> VideoModeNumber = 111h
> 614400 B allocated for FrameBuffer
> WinFuncPtr = C000:1BF4h
> WinGranularity = 64 kB
> NumBanks = 9
> LastSize = 24576 B
> Measured refresh rate = 60.6 Hz
> Measured 45 FPS (FrameBuffer>VRAM)
> (transfer speed 26 MB/s)
>
> I notice that I never enabled write combing under msdos.. Ill try with
> it... mayeb I gain some speed

You are using bank switched mode, enabling LFB should give better result.

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

It works fine for me. Just some questions:

Instead of an initial black screen can you output the message: "Please wait while mupdf is preparing your document" ? This improves the "user experience" for large documents. I have to wait for 10 seconds till the black screen is cleared.

Are there any plans for the support of printing the documents? Or making screenshots and save these as image files? E.g. hit CTRL-PrtScr to save the current screen as mupdf.bmp.

Georg

> It works fine for me. Just some questions:
>
> Instead of an initial black screen can you output the message: "Please wait
> while mupdf is preparing your document" ? This improves the "user
> experience" for large documents. I have to wait for 10 seconds till the
> black screen is cleared.

Maybe, I tested also some huge 80MB PDF (computer magazine) and no delay but I test on fast PC only.

> Are there any plans for the support of printing the documents? Or making
> screenshots and save these as image files? E.g. hit CTRL-PrtScr to save the
> current screen as mupdf.bmp.

I don't know how printing of graphics docs works. Maybe it would be better convert to post script and send as postscript data to printer? If you need output to graphics file use drawpdf with proper page number. But I can save bitmaps it wouldn't be problem...

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

> > I notice that I never enabled write combing under msdos.. Ill try with
> > it... mayeb I gain some speed
>
> You are using bank switched mode, enabling LFB should give better result.

Im testing with this line:

vesatest 640 480 16 lfb and yes.. the test run in LFB mode.. I get better result..

The problem is that I cannot enable LFB in my computer.. Im trying your app MTRRLFBE.EXE and I cannt enable it.

I have same problem with FASTVID. It includes a program to test LFB and yes.. the test run ok.. I got better performance in LFB than in VGA mode.. but again I cannt enable LBS for use it in all my programs

I can enable LFB in my p166mmx .. or that feature is only available for pentium pro, pentium II processors?

> Im testing with this line:
>
> vesatest 640 480 16 lfb and yes.. the test run in LFB mode.. I get better
> result..
>
> The problem is that I cannot enable LFB in my computer.. Im trying your app
> MTRRLFBE.EXE and I cannt enable it.

Maybe there's a confusion.
LFB (Linear FrameBuffer) is a feature of VESA VBE 2.0 that means entire video memory in mapped to your CPU memory address space so no need to call BIOS routines to swap small windows and other mess.

MTRRs are special registers that set caching mode for some memory area (here for LFB area) According to wiki, MTRRs are on intel Pentium Pro and newer so you cannot set it on P1MMX.

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

Well I looked at the black screen and thought if would hang and I would have to reboot. The PC I tested it on is five years old.

Printing (colored) graphics is quite a challenge. If you can convert to Postscript that would be an efficient way to go. The HP printer probably then just needs a command to indicate that a postscript file is send.

In the package I downloaded there was no version of drawpdf for DOS. Maybe you can make an entry under F1 of mupdf which allows to select the pages to convert to an image and then shell out to DOS and call drawpdf to make images of these pages.

Georg

>> Im trying your app
>> MTRRLFBE.EXE and I cannt enable it.


> MTRRs are special registers that set caching mode for some memory area
> (here for LFB area) According to
> wiki,
> MTRRs are on intel Pentium Pro and newer so you cannot set it on P1MMX.

Indeed! Well, here's my report, shall we begin with the bad news...?

- Your MTRRLFBE doesn't work on my AMD K7 CPU / SiS chipset system
It reports about found VESA 3.0, outputs the LFB address, then tells it failed to set the MTRRs. The diagnostic is not precise enough in the absence of source code or adequate app documentation :
Are you deliberately not setting the MTRRs because, maybe, your program doesn't "know" they are present and Intel-compatible ? Or did "something" unexpected happen while trying to set the regs ? Just trying to guess...
I've been running Mtrrlfbe under HDPMI32 in case it matters.

- Your port of the MuPDF is working great out of the box ! That's the *good* (TM) news Very high image quality - and I didn't have any "tweaking" to do.

Cheers...

---
Ninho