DOS ain't dead

travolter 17.02.2011, 10:52	PDF readers for DOS (Users) Post reply
	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?

DOS386

17.02.2011, 11:12

@ travolter

PDF readers for DOS

Post reply

> 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 :clap:

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

Laaca

Czech republic,
17.02.2011, 13:58

@ DOS386

PDF readers for DOS

Post reply

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

Why? I sometimes use it.

---
DOS-u-akbar!

RayeR

CZ,
17.02.2011, 18:24

@ Laaca

PDF readers for DOS

Post reply

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

Arjay

17.02.2011, 20:45

@ RayeR

PDF readers for DOS

Post reply

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

Doug

18.02.2011, 08:07

@ Arjay

Tested PDFTK,,, and MUPDF with HX

Post reply

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

Berlin, Germany,
18.02.2011, 20:59

@ Doug

Tested PDFTK,,, and MUPDF with HX

Post reply

> 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

RayeR

CZ,
19.02.2011, 01:05

@ rr

Tested PDFTK,,, and MUPDF with HX

Post reply

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

RayeR

CZ,
19.02.2011, 02:46
(edited by RayeR, 19.02.2011, 04:23)

@ RayeR

Tested PDFTK,,, and MUPDF with HX

Post reply

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.

DOS386

19.02.2011, 11:27

@ RayeR

MUPDF with HX | MUPDF with DGJPP | XPDF without FONTS

Post reply

> 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 ? :confused:

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

RayeR

CZ,
19.02.2011, 14:16

@ DOS386

MUPDF with HX | MUPDF with DGJPP | XPDF without FONTS

Post reply

> 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 ? :confused:

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.

RayeR

CZ,
19.02.2011, 18:26

@ RayeR

MUPDF/DGJPP test release!

Post reply

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.

RayeR

CZ,
20.02.2011, 03:48

@ RayeR

MUPDF/DGJPP test release!

Post reply

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.

DOS386

20.02.2011, 10:23

@ RayeR

MUPDF/DGJPP test release! CRTC.CFG

Post reply

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

RayeR

CZ,
20.02.2011, 14:07

@ DOS386

MUPDF/DGJPP test release! CRTC.CFG

Post reply

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

Khusraw

Bucharest, Romania,
20.02.2011, 11:36
(edited by Khusraw, 20.02.2011, 12:10)

@ RayeR

MUPDF/DGJPP test release!

Post reply

> 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

RayeR

CZ,
20.02.2011, 13:55

@ Khusraw

MUPDF/DGJPP test release!

Post reply

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

Khusraw

Bucharest, Romania,
20.02.2011, 14:05

@ RayeR

MUPDF/DGJPP test release!

Post reply

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

RayeR

CZ,
20.02.2011, 14:12
(edited by RayeR, 20.02.2011, 15:05)

@ Khusraw

MUPDF/DGJPP test release!

Post reply

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

travolter

20.02.2011, 14:52

@ RayeR

MUPDF/DGJPP test release!

Post reply

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!

RayeR

CZ,
20.02.2011, 15:19

@ travolter

MUPDF/DGJPP test release!

Post reply

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

travolter

20.02.2011, 18:15

@ RayeR

MUPDF/DGJPP test release!

Post reply

> 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 ;/

FFK

21.02.2011, 01:37

@ RayeR

MUPDF/DGJPP test release!

Post reply

> 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

Doug

21.02.2011, 04:31

@ RayeR

MUPDF/DGJPP test release!

Post reply

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

DOS386

21.02.2011, 07:57

@ Doug

MUPDF/DGJPP test release! SHOTS

Post reply

YES it works, thanks :-)

[image]

(deliberately reduced to 15 colors)

[image]

(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 ***

RayeR

CZ,
21.02.2011, 16:43

@ Doug

MUPDF/DGJPP test release!

Post reply

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

Zyzzle

21.02.2011, 07:47

@ RayeR

MUPDF/DGJPP test release!

Post reply

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.

Japheth

Germany (South),
21.02.2011, 08:41

@ RayeR

MUPDF/DGJPP test release!

Post reply

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

Doug

20.02.2011, 06:37

@ RayeR

MUPDF/DGJPP test release!

Post reply

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

RayeR

CZ,
20.02.2011, 14:01

@ Doug

MUPDF/DGJPP test release!

Post reply

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.

Laaca

Czech republic,
20.02.2011, 22:35

@ RayeR

MUPDF/DGJPP test release!

Post reply

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!

Rugxulo

Usono,
21.02.2011, 02:31

@ RayeR

MUPDF/DGJPP test release!

Post reply

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

RayeR

CZ,
21.02.2011, 10:34

@ RayeR

MUPDF/DGJPP test release!

Post reply

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.

travolter

21.02.2011, 15:00
(edited by travolter, 21.02.2011, 15:18)

@ RayeR

MUPDF/DGJPP test release!

Post reply

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

RayeR

CZ,
21.02.2011, 16:34

@ travolter

MUPDF/DGJPP test release!

Post reply

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

travolter

21.02.2011, 19:50

@ RayeR

MUPDF/DGJPP test release!

Post reply

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

RayeR

CZ,
22.02.2011, 01:50
(edited by RayeR, 22.02.2011, 02:48)

@ travolter

MUPDF/DGJPP test release!

Post reply

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

travolter

22.02.2011, 11:12

@ RayeR

MUPDF/DGJPP test release!

Post reply

> 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

RayeR

CZ,
22.02.2011, 13:09

@ travolter

MUPDF/DGJPP test release!

Post reply

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

georgpotthast

Germany,
22.02.2011, 13:35

@ RayeR

MUPDF/DGJPP test release!

Post reply

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

RayeR

CZ,
22.02.2011, 17:15

@ georgpotthast

MUPDF/DGJPP test release!

Post reply

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

georgpotthast

Germany,
22.02.2011, 18:28

@ RayeR

MUPDF/DGJPP test release!

Post reply

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

RayeR

CZ,
23.02.2011, 04:35

@ georgpotthast

MUPDF/DGJPP test release!

Post reply

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

Well, here's next nightbuild beta 0.3
- startup message (I can't see it but hope it will appear esp. for you :)
- push/pop current page to bookmark (multiple)
- take screenshot to uncompressed RGBA TGA files (F12)
- help (F1) stay until key pressed

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

Zyzzle

23.02.2011, 10:59

@ RayeR

MUPDF/DGJPP test release!

Post reply

> Well, here's next nightbuild
> beta 0.3
> - startup message (I can't see it but hope it will appear esp. for you :)
> - push/pop current page to bookmark (multiple)
> - take screenshot to uncompressed RGBA TGA files (F12)
> - help (F1) stay until key presseds

Keeps getting better.

Am I missing something, or is there a way to automatically (ie, intelligently) get it zoom to fit the width of the screen. Manually specifiying the DPI each time is OK, but the zoom to fit screen width would be great.

Also, for some PDFs which are 2- or 3-columns, another neat feature would be to not make PgDn go forward an entire page, but rather only that percentage which had been displayed from the 'zoom to screen-width' feature. For example, suppose the page contains 100 lines of text, but only 30 display when zooming to fit screen width. Then, pgDn (or, maybe pressing down-arrow twice quickly) would display lines 31 to 60, rather than the beginning of the next page... Then again, for lines 61 to 90, etc.

travolter

22.02.2011, 17:18

@ RayeR

MUPDF/DGJPP test release!

Post reply

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

RayeR

CZ,
22.02.2011, 17:26

@ travolter

MUPDF/DGJPP test release!

Post reply

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

Ninho

22.02.2011, 21:05

@ RayeR

MUPDF/DGJPP test release!

Post reply

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

RayeR

CZ,
23.02.2011, 00:27

@ Ninho

MUPDF/DGJPP test release!

Post reply

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

I don't have any running AMD machine to test it. Do you know if MTRRs on AMD are compatible to intel's? My program only chcek CPUID flags if MTRR is s upported but then it doesn't branch for intel and others. Setting of MTRRs are done via RDMSR/WRMSR (so this mean machine specific). Piece of code:

DWord phys_base_ptr_shifted=phys_base_ptr>>12; // phys_base_ptr shifted for structure usage ... mtrr_var_pb.phys_base=phys_base_ptr_shifted; mtrr_var_pb.mode=mode; // set base and mode memcpy(&qw_mtrr_var_pb,&mtrr_var_pb,sizeof(qw_mtrr_var_pb)); // format structure to QWord vesahlp_set_msr(VESA_MTRR_VAR_BASE+j*2,&qw_mtrr_var_pb); // write modified MSR mtrr_var_pm.valid=1; // &0xFFFFFF for 36-bit address mtrr_var_pm.phys_mask=(~(phys_base_ptr_shifted^(phys_base_ptr_shifted+(size_kb>>2)-1)))&0xFFFFFF; memcpy(&qw_mtrr_var_pm,&mtrr_var_pm,sizeof(qw_mtrr_var_pm)); // format structure to QWord vesahlp_set_msr(VESA_MTRR_VAR_BASE+j*2+1,&qw_mtrr_var_pm); // write modified MSR // printf("Setting MTRR #%d...\n",j);

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

Ninho

23.02.2011, 11:43

@ RayeR

MUPDF/DGJPP test release!

Post reply

Hiya RayeR !
>> - Your MTRRLFBE doesn't work on my AMD K7 CPU / SiS chipset system :-(
>> .....

> I don't have any running AMD machine to test it. Do you know if MTRRs on
> AMD are compatible to intel's?

Yes, binary compatible MSRs starting with K7 (at least Athlon XP; am not certain about old plain Athlons) Previously K6/K6-2/K6-3 had their own incompatible mechanisms for write allocate, write combine and like stuff...

> My program only chcek CPUID flags if MTRR is
> s upported but then it doesn't branch for intel and others. Setting of
> MTRRs are done via RDMSR/WRMSR (so this mean machine specific). Piece of
> code:
(snipped)

So this part should be OK on my CPU too.

But then what's going wrong has to be the determination of the LFB address and size. I understand you are querying the VESA BIOS, which on this box provides a false answer :=) Does the your program allow for user-provided address and size ?

From bare DOS, using turbo debugger, I've just checked the MTRRs as set by the BIOS. The range intended for video LFB appears to be 32 Megabytes at D0000000h, which are properly set in a pair of phys_MTTRRs as "type 01" memory (WC). But according to your program (and VESATEST) the VESA BIOS tells the LFB is at C0000000. Moral : don't believe VESA !

Anyway... I'm going to write my own tiny DOS proggie to enable WC on the legacy video buffer - no need for DOS extended bloat in my book.

Cheers

---
Ninho

RayeR

CZ,
23.02.2011, 13:17

@ Ninho

MUPDF/DGJPP test release!

Post reply

> Yes, binary compatible MSRs starting with K7 (at least Athlon XP; am
> not certain about old plain Athlons) Previously K6/K6-2/K6-3 had their own
> incompatible mechanisms for write allocate, write combine and like
> stuff...

OK, then it should work.

> But then what's going wrong has to be the determination of the LFB address
> and size. I understand you are querying the VESA BIOS, which on this box
> provides a false answer :=) Does the your program allow for
> user-provided address and size ?

Yes, did you RTFH?
SYNTAX: MTRRLFBE area mode
area: "VGA" or "LFB" (address range to apply mode change) or
"USER:base_address:size" (base_address is a hexa-number, size is in kB)
mode: "UC" - UnCached, "WP" - Write-Protected, "WT" - Write-Through,
mode: "WB" - Write-Back, "WC" - Write-Combining

> From bare DOS, using turbo debugger, I've just checked the MTRRs as set by
> the BIOS. The range intended for video LFB appears to be 32 Megabytes at
> D0000000h, which are properly set in a pair of phys_MTTRRs as "type 01"
> memory (WC). But according to your program (and VESATEST) the VESA BIOS
> tells the LFB is at C0000000. Moral : don't believe VESA !

Yes I read physlfbprt from VESA VBE info func. So it seems you have rare bug in VESA BIOS. What is other way to determine LFB address (that works on your PC)? What is your VGA? Does others programs work with LFB? I tested it on various VGA with different address of LFB and it was always detected OK.

> Anyway... I'm going to write my own tiny DOS proggie to enable WC on the
> legacy video buffer - no need for DOS extended bloat in my book.

You can save your work, Japheth already wrote an alternative (smaller code) utility according my advice. It's part of HX DOS extender (not HXRT but some other package).

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

Ninho

23.02.2011, 17:19
(edited by Ninho, 23.02.2011, 18:20)

@ RayeR

MUPDF/DGJPP test release!

Post reply

>> But then what's going wrong has to be the determination of the LFB
>> address and size. I understand you are querying the VESA BIOS, which on
>> this box provides a false answer

I had not had an incentive to look into this before, now digging a little further, (plain DOS) : VESA BIOS reports the LFB at C0000000h (3 Giga), and that is correct. But at the same time for some unfathomable reason AMI/SiS BIOS erroneously has pointed the appropriate MTRR (MSR 20E/20F) to phys address D0000000h instead of C0000000. "Plug and play" they say, let me laugh :=)

Correcting the MTRR "by hand" (thanks, o my faithful TD) leads to a 7-fold increase in video speed measurements, using the LFB.

I also tried to enhance video speed legacy bank switched modes by setting the appropraite "fixed range" MTRR at A0000 to "WC" type. Strangely, in this case I don't get any improvements from uncacheable to write combinable. Any idea why ?

> Yes, did you RTFH?
> SYNTAX: MTRRLFBE area mode

I try to RTFthings. I missed that, or I have another version of mtrrlfbe.

> Yes I read physlfbprt from VESA VBE info func. So it seems you have rare
> bug in VESA BIOS. What is other way to determine LFB address (that works on
> your PC)? What is your VGA? Does others programs work with LFB? I tested it
> on various VGA with different address of LFB and it was always detected
> OK.

The other way is taking the LFB address directly from the SiS 741 (north bridge) registers where it resides !

>> Anyway... I'm going to write my own tiny DOS proggie to enable WC on the
>> legacy video buffer - no need for DOS extended bloat in my book.

> You can save your work, Japheth already wrote an alternative (smaller code)
> utility according my advice. It's part of HX DOS extender (not HXRT but
> some other package).

I love to spare me work, in principle, unfortunately it all too often happens that others' work is lacking in one ore another respect <LOL> or in other words, that "one size fits all" is too good to be much more than a sales slogan :=)

Thanks for your efforts and cheers

---
Ninho

RayeR

CZ,
23.02.2011, 19:33

@ Ninho

MUPDF/DGJPP test release!

Post reply

> I had not had an incentive to look into this before, now digging a little
> further, (plain DOS) : VESA BIOS reports the LFB at C0000000h (3 Giga), and
> that is correct. But at the same time for some unfathomable reason
> AMI/SiS BIOS erroneously has pointed the appropriate MTRR (MSR 20E/20F) to
> phys address D0000000h instead of C0000000. "Plug and play" they say, let
> me laugh :=)

That's the plug and pray - the right meaning ;)
>
> Correcting the MTRR "by hand" (thanks, o my faithful TD) leads to a 7-fold
> increase in video speed measurements, using the LFB.

well, so now also mtrrlfbe works?

> I also tried to enhance video speed legacy bank switched modes by setting
> the appropraite "fixed range" MTRR at A0000 to "WC" type. Strangely, in
> this case I don't get any improvements from uncacheable to write
> combinable. Any idea why ?

I don't know exactly but it's usual.

> The other way is taking the LFB address directly from the SiS 741 (north
> bridge) registers where it resides !

But this is HW dependent that I rather avoid.

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

Ninho

23.02.2011, 19:50

@ RayeR

MUPDF/DGJPP test release!

Post reply

>> Correcting the MTRR "by hand" (thanks, o my faithful TD) leads to a 7-fold
>> increase in video speed measurements, using the LFB.

> well, so now also mtrrlfbe works?

No doubt it will - I'll assert it on the next opportunity

>> I also tried to enhance video speed legacy bank switched modes by
> setting
>> the appropriate "fixed range" MTRR at A0000 to "WC" type. Strangely, in
>> this case I don't get any improvements from uncacheable to write
>> combinable. Any idea why ?

> I don't know exactly but it's usual.

Ah, this is what I wished to hear. I have a hypothesis why it could behave thus : the BS memory at A0000-BFFFF has no physical existence, the video chipset has to emulate it and the complicated (S)VGA memory organisation schemes, internally translating addresses to/from linear. In the process optimisations due to write combining are lost completely or almost so. Does it like make sense ?

>> The other way is taking the LFB address directly from the SiS 741 (north
>> bridge) registers where it resides !

> But this is HW dependent that I rather avoid.

Understandably

---
Ninho

DOS386

24.02.2011, 07:50

@ Ninho

MUPDF/DGJPP test release! | progress, LFB, evil PDF 1.7

Post reply

> I checked the link and is still alive, what's the problem?

PROBLEM: msg=9647

> > for major/final release please compile -march=i80386 too.
> As travolter reported not much gain of -march I dropped it.

So march is 80386 again ?

> Hm. Ic.cz sometimes not accessible, it's a free hosting...

It's back ... but VESATEST is from 2005 :-|

> There's no global variable indicating loading progress so I cannot display it.

Heh :-|

> Or do you need useless animated stuff like in windows?

NO. Need "useless bloated stuff like in windows" ? Go to "uloz.to" : msg=9647 :clap:

A simple progress indicator would be cool (bar, number, ...) but if the lib has no support then it's difficult :-(

> This document works fine for me. And it was only ~8MB In header I could saw PDF1.6

Damn. The offending file is here (vanished from Adobe ???): PDF BLOAT (15 MiB, 1.7), please check it.

> For documents I had tried it zoomed all text, vector graphics and bitmaps...

You are missing the point too (or I didn't express it well). I meant that proper PDF elements (fonts, tables, graphs) do NOT pass any bitmap zooming algorithm (Lanczos, SP-line, Bilinear, NN, ...), so you can't "hack" here. Sure it could be made faster and less mice but then you have to replace quality-optimized bitmap brewing algorithms by speed optimized ones.

> LFB appears to be 32 Megabytes at D0000000h,

who said ?

> which are properly set in a pair of phys_MTTRRs as "type 01" memory (WC).
> But according to your program (and VESATEST) the VESA BIOS
> tells the LFB is at C0000000. Moral : don't believe VESA !

Funny :clap: FYI, I have a PC with LFB at 1 Gi AKA $4000'0000.

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

RayeR

CZ,
24.02.2011, 14:20

@ Ninho

MUPDF/DGJPP test release!

Post reply

> Ah, this is what I wished to hear. I have a hypothesis why it could behave
> thus : the BS memory at A0000-BFFFF has no physical existence, the video
> chipset has to emulate it and the complicated (S)VGA memory organisation
> schemes, internally translating addresses to/from linear. In the process
> optimisations due to write combining are lost completely or almost so. Does
> it like make sense ?

But not always. A I reported the core i5 crap, it gained +50% in bankswithed mode and 0% in LFB. It just differs for different hardware...

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

Ninho

25.02.2011, 11:31

@ Ninho

MUPDF/DGJPP test release!

Post reply

>>> Correcting the MTRR "by hand" (thanks, o my faithful TD) leads to a
> 7-fold
>>> increase in video speed measurements, using the LFB.

>> well, so now also mtrrlfbe works?

I'm awfully sorry, have to report it doesn't :(
Sorry about the delay too, I've been busy with quite different things.

Called as either MTRRLFBE LFB WC - or USER:C0000000:16384 WC, it can't set an MTRR and aborts.
______________________________________
VESA 3.0 SiS [16384 kB]
Silicon Integrated Systems Corp.
6330
2.49.00
LFB address: C0000000h
MTRR setting failed.
______________________________________

Without more info on why/how it fails I can't help any more; maybe you're simply aborting as CPUID doesn't report GenuineIntel ? - I'll be happy to run a debugging version if you wish. Anyhoo, last time I was in the turbo-debugger I made a 10 instructions long setwc.com that sets the LFB to "write combining" on this sytem, so I'm all set-up now :)

N.B. on the same machine "VESAtest" does set WC properly when instructed to do so, and measurements are OK.

Cheers

--
Ninho

RayeR

CZ,
25.02.2011, 13:05

@ Ninho

MUPDF/DGJPP test release!

Post reply

______________________________________
> VESA 3.0 SiS [16384 kB]
> Silicon Integrated Systems Corp.
> 6330
> 2.49.00
> LFB address: C0000000h
> MTRR setting failed.
> ______________________________________

Well I'll have a look and provide some debug ver. Can you send me your email?
It would be faster...

> Without more info on why/how it fails I can't help any more; maybe you're
> simply aborting as CPUID doesn't report GenuineIntel ? - I'll be happy to

No I don't branch code according to CPU manufacturer. I just check generic features flag if there's 1 in MTRR bit. similar like when you check if have MMX, SSE, etc...

> turbo-debugger I made a 10 instructions long setwc.com that sets the LFB
> to "write combining" on this sytem, so I'm all set-up now :)

Does this short code also search free MTRR or you write into some fix chosen MTRR?

> N.B. on the same machine "VESAtest" does set WC properly when instructed
> to do so, and measurements are OK.

Hm interesting. Maybe I just need to recompile mtrrlfbe with newer version of my lib, I didn't updated it so long. Does it works with newer vesatest.exe too?

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

Ninho

25.02.2011, 13:40

@ RayeR

MUPDF/DGJPP test release!

Post reply

>> VESA 3.0 SiS [16384 kB]
>> Silicon Integrated Systems Corp.
>> 6330
>> 2.49.00
>> LFB address: C0000000h
>> MTRR setting failed.
>> ______________________________________

> Well I'll have a look and provide some debug ver. Can you send me your
> email?
I'll PM you with an email address

> I don't branch code according to CPU manufacturer. I just check generic
> features flag if there's 1 in MTRR bit. similar like when you check if have
> MMX, SSE, etc...

I presume that would be CPUID std function 01 -> EDX_bit12, right ? Bit is properly SET (1) by the CPU...

>
>> turbo-debugger I made a 10 instructions long setwc.com that sets the
> LFB
>> to "write combining" on this sytem, so I'm all set-up now :)

> Does this short code also search free MTRR or you write into some fix
> chosen MTRR?

It's just a custom hack, not general purpose - although it wouldn't be difficult to extend it a little... I'm just correcting MTRRs #6 and 7, using known proper values for my hardware.

>> N.B. on the same machine "VESAtest" does set WC properly when instructed
>> to do so, and measurements are OK.

> Hm interesting. Maybe I just need to recompile mtrrlfbe with newer version
> of my lib, I didn't updated it so long. Does it works with newer
> vesatest.exe too?

Shall see...

--
N.

Ninho 25.02.2011, 20:37 @ RayeR	MTRRLFBE -Good news ! Post reply
	The recompiled Mtrrlfbe you sent me today worked like a charm on my K7, out of the (mail)box ! Well done! It appears there'll be no need to plunge into the beast's guts after all... Cheers -- Ninho

RayeR

CZ,
26.02.2011, 01:02

@ Ninho

MTRRLFBE -Good news !

Post reply

> The recompiled Mtrrlfbe you sent me today worked like a charm on my K7, out
> of the (mail)box ! Well done! It appears there'll be no need to plunge into
> the beast's guts after all...
>
> Cheers
>
> --
> Ninho

Thx for testing, I'll upload new version to my website :)
Next task would be to beat core i3/5/7 crap but I'm not going to upgrade yet...

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

Ninho

20.03.2011, 19:30

@ RayeR

more insight into BIOS MTRRs

Post reply

>> I had not had an incentive to look into this before, now digging a little
>> further, (plain DOS) : VESA BIOS reports the LFB at C0000000h (3 Giga), and
>> that is correct. But at the same time for some unfathomable reason
>> AMI/SiS BIOS erroneously has pointed the appropriate MTRR (MSR 20E/20F) to
>> phys address D0000000h instead of C0000000. "Plug and play" they say, let
>> me laugh :=)

> That's the plug and pray - the right meaning ;)

I always thought the right interpretation was pay and pray ;-)

...However, I gave the whole story a second look & changed my opinion, it's
no BIOS bug; rather the region, starting at D0000000, set to write-combining is the "AGP
aperture", not the LFB - the latter is left for an OS to set presumably.

Looking from Windows now, neither Win 98 nor 2k set an MTRR over the frame
buffer. I guess for such purpose they are using the PAT instead.

---
Ninho

RayeR

CZ,
23.03.2011, 20:18

@ Ninho

more insight into BIOS MTRRs

Post reply

> Looking from Windows now, neither Win 98 nor 2k set an MTRR over the frame
> buffer. I guess for such purpose they are using the PAT instead.

I don't know anything about PAT yet, have some good docs?
Maybe it's way to solve core i3/5/7 issue. BTW I got some test results from intel onboard vga 845-945G and it's interesting that BS mode gain performance ~10x but LFB mode only 10-20% when MRTT set.

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

Laaca

Czech republic,
23.03.2011, 23:25

@ RayeR

more insight into BIOS MTRRs

Post reply

> I don't know anything about PAT yet, have some good docs?
> Maybe it's way to solve core i3/5/7 issue.

Hm.. Maybe.
I found this snippet from discussion:

Liang Yang wrote:
> Hi,
>
> It seems we can set the memory access type (WB, WC, WT etc.) by either using
> PAT or MTRR on x86 CPUs.
> My question is:
> Are PAT and MTRR always consistent with each other? If there is
> inconsistence between them, which one decides the true memory access type?

This is well documented in the Intel references, but in short, the
cache control bits in the page tables (including those indirectly
referenced via the PAT) and the caching controls in the MTRRs are
largely independent of one another. That being said, if caching
controls are set for a given location by more than once mechanism, the
most restrictive (least amount of caching) policy specified wins. Thus
if the MTRR specifies no caching but the page table specifies
cacheable, the page is uncached, the reverse scenario (MTRR::cacheable,
page:uncachable) also results in an uncachable page.

Several other rules apply, for example, if write through is specified
in one place and write back in the other, write through wins.

---
DOS-u-akbar!

RayeR

CZ,
24.03.2011, 16:20

@ Laaca

more insight into BIOS MTRRs

Post reply

> That being said, if caching
> controls are set for a given location by more than once mechanism, the
> most restrictive (least amount of caching) policy specified wins.

Well. from what CPUID the PAT is supported and how can I check if CPU support pat? I guess that C2D support it. In my case MTRRLFBE sets only MTRRs but it works fine even with PAT not set or set by default. According to mentioned rule if PAT not set it shouldn't work MTRR setting but it worsk. But only on C2D and older. Does it mean that BIOS sets PAT but not set MTRR and on new core i3/5/7 it doesn't set neither MTRR nor PAT?

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

Ninho

24.03.2011, 16:56

@ RayeR

more insight into BIOS MTRRs

Post reply

>> That being said, if caching
>> controls are set for a given location by more than once mechanism, the
>> most restrictive (least amount of caching) policy specified wins.

Right, and quite logical too.

> Well. from what CPUID the PAT is supported and how can I check if CPU
> support pat?

I think PAT first made their appearence with Pentium 3, and AMD included them starting with K7 - Athlon XP for sure, older Athlon : don't know. My old K6-2+ certainly does not support them. But anything modern /must/.

>I guess that C2D support it. In my case MTRRLFBE sets only
> MTRRs but it works fine even with PAT not set or set by default. According
> to mentioned rule if PAT not set it shouldn't work MTRR setting but it
> worsk. But only on C2D and older. Does it mean that BIOS sets PAT but not
> set MTRR and on new core i3/5/7 it doesn't set neither MTRR nor PAT?

MTRRLBE is designed (mainly) for real mode (DOS), there paging nor the PAT mechanism can work !

--
Ninho

RayeR

CZ,
25.03.2011, 00:38

@ Ninho

more insight into BIOS MTRRs

Post reply

> MTRRLBE is designed (mainly) for real mode (DOS), there paging nor the PAT
> mechanism can work !

Not for realmode progs only. DJGPP apps using CWSDPMI that supports and enable paging.

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

Ninho

26.03.2011, 11:41

@ RayeR

more insight into BIOS MTRRs

Post reply

>> MTRRLBE is designed (mainly) for real mode (DOS), there paging nor the PAT
>> mechanism can work !

> Not for realmode progs only. DJGPP apps using CWSDPMI that supports and
> enable paging.

Granted - hence my "mainly" parenthesis - however what need is there to mess with memory typing under a protected mode OS which has set it up itself ;=)

Especially considering such OSes use page table flags for that purpose rather than MTRRs, as noted up thread.

--
N.

Laaca

Czech republic,
29.03.2011, 18:12

@ Ninho

more insight into BIOS MTRRs

Post reply

PAT support can be obtained from CPUID directly:

mov EAX,1
CPUID
test edx,10000h
jz @PAT_present

---
DOS-u-akbar!

RayeR

CZ,
29.03.2011, 22:03

@ Laaca

more insight into BIOS MTRRs

Post reply

> PAT support can be obtained from CPUID directly:
>
> mov EAX,1
> CPUID
> test edx,10000h
> jz @PAT_present

Oh yes, i display this flag in my CPUID utility too :)

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

Japheth

Germany (South),
23.02.2011, 18:14

@ RayeR

MUPDF/DGJPP test release!

Post reply

> You can save your work, Japheth already wrote an alternative (smaller code)
> utility ...

Yes, but it is still "DOS extended bloat". :-D

---
MS-DOS forever!

RayeR

CZ,
23.02.2011, 19:36

@ Japheth

MUPDF/DGJPP test release!

Post reply

> > You can save your work, Japheth already wrote an alternative (smaller
> code)
> > utility ...
>
> Yes, but it is still "DOS extended bloat". :-D

I would use a big hammer to hardwire it, that's definitely not bloat! :-D

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

Ninho 25.02.2011, 15:30 @ Japheth	MUPDF/DGJPP test release! Post reply
	>> You can save your work, Japheth already wrote an alternative (smaller code) >> utility ... > Yes, but it is still "DOS extended bloat". Indeed ... but I just confirmed, it does work on my K7. Regards -- N.

DOS386

23.02.2011, 06:56

@ Ninho

MUPDF/DGJPP test release | missing PDFDRAW.EXE | source cod

Post reply

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

Anyone got the file ? Please upload it to omp :-)

> 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

Seems to work on early pentium with MMX ... for major/final release please compile -march=i80386 too.

> BTW there's short help if you press F1

Bright yellow text on white ... what about adding a dark background ? ;-)

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

Updated 2010-Apr ... did you fix the "EMM386 vs Ring0" flaw ?

http://rayer.ic.cz/ wrote:

> Service Temporarily Unavailable
> The server is temporarily unable to service your request due to maintenance
> downtime or capacity problems. Please try again later

> Instead of an initial black screen can you output the message: "Please wait while mupdf is preparing your document" ?

Right ... or a progress indicator ;-)

> This improves the "user experience" for large documents.
> I have to wait for 10 seconds till the black screen is cleared.

Depends from document ...

> 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

Screen or page ? Being able to save the full page just from MUPDF would be cool (but there is PDFDRAW.EXE ... I just can't download it ... F***).

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

Depends from page size only, not amount of pages ?

> I don't know how printing of graphics docs works

ESC/P2 (old standard) or @#$%@%# (non-standard printers) ... or just save BMP (one page or all) and export the responsability to deal with the printer.

> LFB (Linear FrameBuffer) is a feature of VESA VBE 2.0 that means entire video memory in
> mapped to your CPU memory address space

no 64 KiB limit , no B*** S*** :-)

> MTRRs are special registers that set caching mode for some memory area (here for LFB area)

Faster big and well aligned writes, slower or unreliable (?) reads ;-)

> - Your MTRRLFBE doesn't work on my AMD K7 CPU / SiS chipset system

Use some CPUID tool (by RayeR or other) and post results. :hungry:

> reports about found VESA 3.0, outputs the LFB address

no MTTRR obligation

> then tells it failed to set the MTRRs.

not present ???

> The diagnostic is not precise enough in the absence of source code or adequate app documentation

WRTFM please. Source code of VESATEST would be nice but is not absolutely needed if no 3rd party GPL'ed code included. Source code for MUPDF is a must, see GPL (same would apply to MPLAYER ...) :-(

PDF 1.7 doesn't work: http://www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf

(or at least my copy of this, downloaded in the past, 16'072'714 Byte's of bloat)

Much PDF bloat: http://www.adobe.com/devnet/pdf/pdf_reference_archive.html

Anyone has smaller 1.7 PDF's to test ?

> equest: 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

Are you missing something ??? MUPDF doesn't ZOOM the fonts nor the graphical elements (see shots far above), it just brews them in the final size !!! It does zoom embedded bitmaps, though (and there is no way to find out the "dpi" value for leaving them as-is :-( )

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

RayeR

CZ,
23.02.2011, 10:39

@ DOS386

MUPDF/DGJPP test release | missing PDFDRAW.EXE | source cod

Post reply

> Anyone got the file ? Please upload it to omp :-)

I checked the link and is still alive, what's the problem? To write four chars captcha?

> Seems to work on early pentium with MMX ... for major/final release please
> compile -march=i80386 too.

As travolter reported not much gain of -march I dropped it.

> Bright yellow text on white ... what about adding a dark background ? ;-)

Blue now :) But will be a window...

> Updated 2010-Apr ... did you fix the "EMM386 vs Ring0" flaw ?

Not yet. I didn't received that it would be problem for more people so priority is low. My lib is still under devel. so one day I'll replace msr code with one that's used in cpuid utility...

> http://rayer.ic.cz/ wrote:
>
> > Service Temporarily Unavailable
> > The server is temporarily unable to service your request due to
> maintenance
> > downtime or capacity problems. Please try again later

Hm. Ic.cz sometimes not accessible, it's a free hosting...

> Right ... or a progress indicator ;-)

There's no global variable indicating loading progress so I cannot display it. Or do you need useless animated stuff like in windows?

> Screen or page ? Being able to save the full page just from MUPDF would be
> cool (but there is PDFDRAW.EXE ... I just can't download it ... F***).

I save entire page, it's easier once loaded all :)

> Use some CPUID tool (by RayeR or other) and post results. :hungry:

Cpuid only tells the flag from cpu feature list it's needed to study some AMD CPU datasheet how MTRRs works there and on what MSRs are mapped.

> WRTFM please. Source code of VESATEST would be nice but is not absolutely
> needed if no 3rd party GPL'ed code included. Source code for MUPDF is a
> must, see GPL (same would apply to MPLAYER ...) :-(

Of course I'll give all mupdf modified files and new dos_main.c

> http://www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf

This document works fine for me. And it was only ~8MB In header I could saw PDF1.6

> Are you missing something ??? MUPDF doesn't ZOOM the fonts nor the
> graphical elements (see shots far above), it just brews them in the final
> size !!! It does zoom embedded bitmaps, though (and there is no way to find
> out the "dpi" value for leaving them as-is :-( )

For documents I had tried it zoomed all text, vector graphics and bitmaps...

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

jassenna

Campinas,SP,Brazil,
13.06.2011, 04:30

@ RayeR

MUPDF/DGJPP test release | missing PDFDRAW.EXE | source cod

Post reply

Also missing use instructions, I think. Maybe I am not so clever as
you, but so far, mupdf did not work at all for me.
I downloaded it from http://rayer.ic.cz/350d/mupdf_07_dos.zip
Unzipping the file produced just two files: MUPDF.EXE and CRTC.CFG
I tried "mupdf path\pdffile.pdf" and all it produced was a blank
(completely dark) screen that did not respond to ctrl-c nor ctrl-brk
The DPMI server I am using is Japheth's HDPMI32; O/S is DRDOS 5.0 and
video card a Diamond Stealth VESA VLB.
All .pdf files I tried did exist and xpdf (pdftext and pdfimgs) were
able to extract text and jpeg's from them.

DOS386

03.07.2011, 04:05

@ jassenna

MUPDF/DGJPP test release | missing PDFDRAW.EXE | source cod

Post reply

> Also missing use instructions, I think. Maybe I am not so clever as
> you, but so far, mupdf did not work at all for me.
> I downloaded it from http://rayer.ic.cz/350d/mupdf_07_dos.zip
> Unzipping the file produced just two files: MUPDF.EXE and CRTC.CFG

Good. CRTC.CFG is not really needed, try to kick it (bad values ???)

> I tried "mupdf path\pdffile.pdf" and all it produced was a blank
> (completely dark) screen that did not respond to ctrl-c nor ctrl-brk

Bad, looks like a memory or VESA problem.

> The DPMI server I am using is Japheth's HDPMI32; O/S is DRDOS 5.0

DREMM386 ??? Kick it.

> and video card a Diamond Stealth VESA VLB.

VESATEST says what about it ???

> All .pdf files I tried did exist and xpdf (pdftext and pdfimgs) were
> able to extract text and jpeg's from them.

Because, it looks like a memory or VESA problem, not PDF file problem.

Your CPU and RAM size ???

> > MuPDF 0.8 (2011-03-03)
> > We have improved the image scaling code. We now use an
> > algorithm based on a Graphics Gem when downscaling images,
> > and simple bilinear interpolation when magnifying images.
> > The results are vastly improved legibility of documents

MU ( http://mupdf.com/news.html ) wrote:

> MuPDF 0.8.165 now with XPS (2011-04-29)
> The Open XML Paper Specification is a page description language
> developed by Microsoft. XPS is used extensively in the Vista and
> Windows 7 printing pipeline. The XPS Document Writer is a virtual
> printer that works like Acrobat distiller, but is integrated in Windows
> and creates XPS documents.
> We now proudly announce that MuPDF can read these XPS documents!

DAMN :surprised:

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

jassenna

Campinas,SP,Brazil,
06.07.2011, 06:40

@ DOS386

MUPDF/DGJPP test release | missing PDFDRAW.EXE | source cod

Post reply

> > Also missing use instructions, I think. Maybe I am not so clever as
> Good. CRTC.CFG is not really needed, try to kick it (bad values ???)
I tried without CRTC.CFG. After about one minute, a start message
appeared, the some info about the VESA card (all too fast to read),
then the program crashed. The crash message said:
"Raised at eip=006c55cc
eax=00770500 ebx=00000120 ecx=006e3810 edx=00000008 esi=00778d30 edi=008afb28
ebp=007705c8 esp=007704f0 program=C:\DNLD\MUPDF\MUPDF.EXE
cs: sel=00af base=00111000 limit=008bffff
ds: sel=00b7 base=00111000 limit=008bffff
es: sel=00b7 base=00111000 limit=008bffff
fs: sel=00c7 base=00000000 limit=0010ffff
gs: sel=00c7 base=00000000 limit=0010ffff
ss: sel=00b7 base=00111000 limit=008bffff
App stack: [00778b58..006f8b58] Exceptn stack: [006f8a84..006f6b44]

Call frame traceback EIPs:
0x006c5527
0x006c55cc
0x006c3240
0x0001a460
0x006c123f "

gt; DREMM386 ??? Kick it.
No, JEMMEX 5.74B

> VESATEST says what about it ???
I do not have VESATEST, but some testing with INT10.4F00
revealed a VESA 1.2 card, with capabilities flag=0000, 2 MB
memory and supporting modes 100-107,109,10A,110-117 and 211.

> Your CPU and RAM size ???
486DX50 with 16 MB RAM

Rugxulo

Usono,
06.07.2011, 06:43

@ jassenna

MUPDF/DGJPP test release | missing PDFDRAW.EXE | source cod

Post reply

> I tried without CRTC.CFG. After about one minute, a start message
> appeared, the some info about the VESA card (all too fast to read),
> then the program crashed.

:-(

> > VESATEST says what about it ???
> I do not have VESATEST,

http://rayer.ic.cz/programm/vesatest.zip

> but some testing with INT10.4F00
> revealed a VESA 1.2 card, with capabilities flag=0000, 2 MB
> memory and supporting modes 100-107,109,10A,110-117 and 211.

Have you tried UNIVBE?

jassenna

Campinas,SP,Brazil,
19.07.2011, 06:20

@ Rugxulo

MUPDF/DGJPP test release | missing PDFDRAW.EXE | source cod

Post reply

>
> > > VESATEST says what about it ???
It says the same about the card capabilities and modes as I found
using INT10.4F. So does vesainfo.exe, a program that came with Acrobat
for DOS. In addition, vesatest starts testing the video modes and
crashes after a few screens.
> > but some testing with INT10.4F00
> > revealed a VESA 1.2 card, with capabilities flag=0000, 2 MB
> > memory and supporting modes 100-107,109,10A,110-117 and 211.
In addition, the card supports only one memory window and 24 bit color.
> Have you tried
> UNIVBE?
I did , and the only difference it made was that MUPDF reports
VESA 2.0 instead of 1.2 in its start message. BTW, I also tried
Acrobat for DOS with univbe.drv installed, and it made very little
or no difference.

IMHO, the problem is that MUPDF demands too much CPU, video or
memory performance to run in this machine.

jassenna Campinas,SP,Brazil, 20.08.2011, 06:24 @ jassenna	MUPDF/DGJPP test release \| missing PDFDRAW.EXE \| source cod Post reply
	> IMHO, the problem is that MUPDF demands too much CPU, video or > memory performance to run in this machine. Would it be too difficult to port PDFDRAW instead, so users could convert a pdf file to a set of one-page images, then view them using one of the picture viewers available in DOS ?

DOS386

21.08.2011, 15:56

@ jassenna

PDFDRAW.EXE worx for me :-)

Post reply

> didn't actually delete "pl1", but the way things are currently set up, I moved it to "old",
> which for whatever reason doesn't show up (and won't let me fix it either, blech).

Some administrator will have to run some filesystem decorruptor :hungry:

> Well, honestly, who needs it?

When it's recovered then you can kick it ;-)

> Lucky ... usually things never work for me.

Steps to reproduce the problem ?

> Too bad more Win32 people don't test more with HX (esp. when dropping DJGPP)

Right :-)

> Would it be too difficult to port PDFDRAW instead

of what ??? Sure one could port PDFDRAW ...

FYI, PDFDRAW.EXE (Win32) works for me in DOS (can output text or PNG/PPMD pages).

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

jassenna

Campinas,SP,Brazil,
22.08.2011, 04:32

@ DOS386

PDFDRAW.EXE worx for me :-)

Post reply

> > Would it be too difficult to port PDFDRAW instead

> of what ??? Sure one could port PDFDRAW ...

> FYI, PDFDRAW.EXE (Win32) works for me in DOS (can output text or
> PNG/PPMD pages ).

Please give more information:
1) Do you use HX for this ?
2) Where can I find the version of PDFDRAW you refer to ?
3) Perhaps PDFDRAW is not what I think it is : text or PNG/PPMD
means it extracts text and images from the file, as does XPDF ?
I thought it did create page-by-page images, but save them instead of
displaying them.

DOS386

04.09.2011, 12:21

@ jassenna

PDFDRAW.EXE | RTFW

Post reply

> 1) Do you use HX for this ?

Considering that no DOS kernel supports Win32 apps natively :confused:

> 2) Where can I find the version of PDFDRAW you refer to ?

Official download page ?

> 3) Perhaps PDFDRAW is not what I think it is : text or PNG/PPMD

IT IS :clap:

> I thought it did create page-by-page images, but save them instead of displaying

Right.

RTFW

Did you get it working ?

PS: Did you get EDR-DOS working ?

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

DOS386

09.09.2011, 18:48

@ DOS386

PDFDRAW.EXE | RTFW | MU 0.9 2011-09-05

Post reply

MU wrote:

> MuPDF 0.9 (2011-09-05)
> This is a bug fix and stability release. No new features to report.

Nobody knows what bugs actually got fixed ... if ever. But Igor does like that too :-)

BTW, PDFDRAW seems to still work.

PS: 99 posts :clap:

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

jassenna

Campinas,SP,Brazil,
10.09.2011, 07:28

@ DOS386

PDFDRAW.EXE | RTFW

Post reply

DOS386 said:

> Official download page ? :confused:

> RTFW

Or unofficial, as you prefer. I read the wiki page you mentioned,
but it does not have any download url for pdfdraw. The MUPDF zip file
I downloaded through the link provided in this forum has mupdf only,
no pdfdraw.
Please excuse me for asking things that may be obvious, but this
thread is the first place where I saw anything about pdfdraw.

PS-I am using EDR-DOS now.

Rugxulo

Usono,
10.09.2011, 23:38

@ jassenna

PDFDRAW.EXE | RTFW

Post reply

> DOS386 said:
>
> > RTFW
>
> Or unofficial, as you prefer. I read the wiki page you mentioned,
> but it does not have any download url for pdfdraw. The MUPDF zip file
> I downloaded through the link provided in this forum has mupdf only,
> no pdfdraw.
> Please excuse me for asking things that may be obvious, but this
> thread is the first place where I saw anything about pdfdraw.
>
> PS-I am using EDR-DOS now.

I have not tried, but I assume he means use HX + the Win32 binary (PDFDRAW.EXE) located here:

http://www.mupdf.com/
http://code.google.com/p/mupdf/downloads/list

6356992 09/05/2011 13:14 mupdf-0.9-windows/pdfdraw.exe

DOS386

11.09.2011, 07:58

@ Rugxulo

PDFDRAW.EXE | RTFW

Post reply

> use HX + the Win32 binary (PDFDRAW.EXE) located here:
> http://www.mupdf.com/ http://code.google.com/p/mupdf/downloads/list

or http://jafile.com/uploads/dos386/pdfdraww.zip

BTW, MUPDF.EXE doesn't work:

[image]

http://jafile.com/uploads/dos386/win_main.c

/* Create window */ hwndframe = CreateWindowW(L"FrameWindow", // window class name NULL, // window caption WS_OVERLAPPEDWINDOW | WS_CLIPCHILDREN, CW_USEDEFAULT, CW_USEDEFAULT, // initial position 300, // initial x size 300, // initial y size 0, // parent window handle 0, // window menu handle 0, // program instance handle 0); // creation parameters if (!hwndframe) win32error("cannot create frame: %s");

There is a problem with CreateWindowEx (bug or missing feature) :-(

PS: ftp://ftp.sac.sk/pub/sac/graph/s3vbe318.zip
PPSS: Ctyme is fine in Arachne

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

jassenna Campinas,SP,Brazil, 22.09.2011, 06:08 @ DOS386	PDFDRAW.EXE \| RTFW Post reply
	Thank you very much for the links. Unfortunately, neither PDFDRAW works. It terminated with a "Fatal Error: Out of Memory" in the tests I performed. At least it did not crash, but still is not a viable pdf viewer/converter for DOS.

DOS386

20.11.2011, 04:42

@ jassenna

PDFDRAW.EXE | RTFW | PDFDRAW issues | | 16 MiB

Post reply

> Thank you very much for the links.
> Unfortunately, neither PDFDRAW works. It terminated with a
> "Fatal Error: Out of Memory" in the tests I performed. At least it
> did not crash, but still is not a viable pdf viewer/converter for DOS

It IS ... but it needs cca 16 to 32 MiB RAM to run ... BTW, it works on Pentium 1 too :-)

> > Your CPU and RAM size ???
> 486DX50 with 16 MB RAM

Issues:

* hangers on exit (remarkable on slow PC's)
* extract text feature broken (memory leak, crashes)
* destination filename is not fool-proof

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

ron

Australia,
09.04.2011, 03:08

@ Ninho

MUPDF/DGJPP test release!

Post reply

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

Same for me. Worked just fine. Also functions well as a helper for DOS Controller.
Would probably make an excellent add-on for Arachne.

---
AUSREG Consultancy http://www.ausreg.com
Tadpole Tunes http://www.tadpoletunes.com
Sna Keo Il http://www.tadpoletunes.com/sna_keo_il/

KormaX

01.11.2017, 00:23

@ Ninho

MUPDF/DGJPP test release!

Post reply

For the honour of DOS!

If anybody is still interested, I am using this tool to view PDF-s on DOS:

http://www.nomdo.dds.nl/psview.htm

It is actually a controller to PDF2PS, GhostScript and LXPIC in order to convert .PDF to a temporary postscript file, than converting it to temporary .PCX pictures and than displaying them in LXPIC. It works fine, but I use it with a batch script placing all the components into a RAM-disk so no real disk read-write stuff happens after "loading" all the stuff once. Also thanks for the Arachne packages, most of the links stille works so I downloaded a lot of them to try :D

---
DOS isn't about why. It's about why not.

Doug

26.02.2011, 19:02

@ RayeR

A couple of MuPDF bugs.

Post reply

RayeR -

Hey. I'm enjoying using the MuPDF port -- it makes working in
DOS (in which i do 90% of my work... by choice!) way nicer.

Anyway, i have two bugs to report:

1) Between beta 1 and beta 2: MuPDF opens on page 2 rather than
page 1 for multipage documents. (Beta 1 works ok; beta 2 has the
bug.)

2) On some (but not all) PDFs, Red and Blue get switched -- blues
(pure or in combo) get displayed as red and vice versa. (All
your MuPDF versions have the bug. PDFDraw works ok though.)

I have some PDFs that demonstrate, but I couldn't find how to do
attachments here. (I'm too old school -- duh!)

- Doug B.

RayeR

CZ,
28.02.2011, 10:25

@ Doug

A couple of MuPDF bugs.

Post reply

> RayeR -
>
> Hey. I'm enjoying using the MuPDF port -- it makes working in
> DOS (in which i do 90% of my work... by choice!) way nicer.
>
> Anyway, i have two bugs to report:
>
> 1) Between beta 1 and beta 2: MuPDF opens on page 2 rather than
> page 1 for multipage documents. (Beta 1 works ok; beta 2 has the
> bug.)

Did you tried also with last beta 0.3 (already posted here)
http://rayer.ic.cz/350d/mupdf_07_dos.zip ? I got opened page 1.

> 2) On some (but not all) PDFs, Red and Blue get switched -- blues
> (pure or in combo) get displayed as red and vice versa. (All
> your MuPDF versions have the bug. PDFDraw works ok though.)
>
> I have some PDFs that demonstrate, but I couldn't find how to do
> attachments here. (I'm too old school -- duh!)

Hm that's I'm afraid of that it would sometimes require color conversion. So I cannot rely that engine gives me always RGBA order :( First I need to know how to read the current color format. If the affected PDF is up to few megs send me it via mail.
I currently have headaches with my pmode MSR code in AT&T inline assembler :\ and stupid gcc optimizations so nothing new on mupdf...

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

Doug

02.03.2011, 07:54

@ RayeR

A couple of MuPDF bugs.

Post reply

> Did you tried also with last beta 0.3 (already posted here)
> http://rayer.ic.cz/350d/mupdf_07_dos.zip
> ? I got opened page 1.

Oops... beta 3 must've slipped by me somehow. Ok, i downloaded it, and beta 3 works ok as far as opening a file on page 1.

> Hm that's I'm afraid of that it would sometimes require color conversion.
> So I cannot rely that engine gives me always RGBA order :( First I need to
> know how to read the current color format. If the affected PDF is up to few
> megs send me it via mail.

I can send a couple of small PDF files that exhibit the RGB/BGR bug, but i can't seem to find an email address for you. Not listed on your "User info" page, and when i click on "Personal message to RayeR", i still can't see how to attach files!

If you want, you can PM me (i think my address is listed), and i can email the files to you. Or i can just email you the URLs i downloaded the PDFs from.

- Doug B.

DOS386

05.03.2011, 10:14
(edited by DOS386, 05.03.2011, 10:38)

@ RayeR

DAMN: 0.8 is out | MuPDF bugs GOTO scroll LEFT RIGHT Crash

Post reply

MUPDF (and even ACRO 1.0 !?!?!?) can view a document converted by AntiWorld:

[image]

Regrettably there are minor and major bugs (see shot, but also truncated content ...)

[image]

COOL, date, compiler and Author is in :-)

....................

http://jafile.com/uploads/dos386/pdfoct23.pdf (15 MiB)

[image]

Any technology to extract subdocuments except Sumatra (added in 1.2, can view and even save them) ?

> 1.2 (2010-11-26):
> Changes in this relase:
> open embedded PDF documents
> allow saving PDF document attachements to disk

Rayer wrote:

> Did you tried also with last beta 0.3 (already posted here)
> http://rayer.ic.cz/350d/mupdf_07_dos.zip

> I currently have headaches with my pmode MSR code in AT&T inline assembler
> :\ and stupid gcc optimizations so nothing new on mupdf...

Bugs found in 0.3:

TFM ( http://mupdf.com/manual.html wrote ) :

> h, j, k, l scroll page
> 123g go to page 123

- Scroll LEFT and RIGHT doesn't work
- GOTO doesn't work
- Crash (rarely) .... offending document has cca 1'000'000 pages and crash occurs at page cca 500'000 so it might be a good idea to fix GOTO before investigating this one ;-)

MU ( http://mupdf.com/news.html ) wrote:

> MuPDF 0.8 (2011-03-03)
> We have improved the image scaling code. We now use an
> algorithm based on a Graphics Gem when downscaling images,
> and simple bilinear interpolation when magnifying images.
> The results are vastly improved legibility of documents

DAMN :-|

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

Doug

19.02.2011, 22:02

@ RayeR

Why different dependency errors with HX?

Post reply

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

RayeR

CZ,
21.02.2011, 16:37

@ Doug

Why different dependency errors with HX?

Post reply

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

travolter 18.02.2011, 12:24 @ DOS386	PDF readers for DOS Post reply
	> > 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 ;)

ron

Australia,
17.02.2011, 22:13

@ travolter

PDF readers for DOS

Post reply

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

DOS386

18.02.2011, 04:10

@ ron

PDF readers for DOS

Post reply

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

ron

Australia,
18.02.2011, 06:04

@ DOS386

PDF readers for DOS

Post reply

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

bocke

26.09.2011, 22:15

@ DOS386

PDF readers for DOS

Post reply

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

There are some FreeDOS builds here: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/gs/. They are not the most recent (2008) but I would guess they are recent enough. Using GhostScript directly wouldn't be as comfortable as using a frontend. Usually, gs file.pdf would show a file automatically and pressing "return" key would change a page. I'm not sure if there is any way to control the flow of the document rendering (ie if you could go to a previous page or similar), but I would suppose not. So you really need a frontend. Makes the life much easier. If you're really interested there is also an online manual:
http://ghostscript.com/doc/8.63/Use.htm

Of course, if you don't need 16-bit. Otherwise, there is a really old 16-bit build of GS 2.6, but I don't know how useful it is nowadays.

Btw, I can't remember if there is a native port of SDL to DOS. I know you can run some win32 SDL apps using Hx, but was wondering about native option.

Anyway, I tried googling for some PDF readers/tools that might be portable to DOS or runnable with Hx:

Green - an SDL PDF reader
https://github.com/schandinat/green/wiki/
Nupdf - it uses mupdf library for rendering and SDL for GUI
http://en.qi-hardware.com/wiki/Nupdf
PoDoFo - a pdf manipulation library and a couple of command line tools
http://podofo.sourceforge.net/about.html
pdftohtml - converts pdf to html, based on xpdf
http://pdftohtml.sourceforge.net/

There are also online pdf to html converters and viewers. Those usually have a bloated interface or are based on flash pdf viewing component. But there is an FOSS pdf viewer with a simple interface at: http://view.samurajdata.se/. I tried the online interface but couldn't upload the file. Haven't tried installing the script locally and running it from my machine. It will require a browser with the image support as it renders the pages as a gif images.

bocke 28.09.2011, 01:55 @ bocke	PDF readers for DOS Post reply
	I didn't get an answer on DOS SDL port. :) Is this possible at all?

jassenna

Campinas,SP,Brazil,
07.11.2017, 00:54

@ ron

PDF readers for DOS

Post reply

ron said:
> 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 !

What machine are you using ?
Are you using it under "pure" DOS or an emulator ?

I found Arachne quite clumsy in a 486 running DOS
and GhostScript barely better than nothing, as it only
allows viewing page by page, without pan, zoom ,scroll
or going back.

DOS386

17.08.2011, 10:55

@ travolter

PDF readers for DOS | XPDF 3.03 - 2011-Aug-15

Post reply

4+1/2 years after 3.02, XPDF 3.03 is out (untested) :-)

What's new:

* http://www.foolabs.com/xpdf/CHANGES (huuuuuuuuuuuuge list)
* http://www.foolabs.com/xpdf/download.html no DGJPP binaries anymore (HX used to work with 3.02)

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

Rugxulo

Usono,
18.08.2011, 02:01

@ DOS386

PDF readers for DOS | XPDF 3.03 - 2011-Aug-15

Post reply

> 4+1/2 years after 3.02, XPDF 3.03 is out (untested) :-)
>
> * http://www.foolabs.com/xpdf/download.html no DGJPP binaries anymore (HX
> used to work with 3.02)

He seems to claim (on the site) to only host compiles he built himself. Perhaps he'll come out with a DJGPP build in the next few days (though I'm not holding my breath).

Anyways, I've already grabbed 3.02pl5 recently, so I should just mirror that for us later tonight (iBiblio only has 3.02pl1).

Rugxulo Usono, 18.08.2011, 02:24 @ Rugxulo	PDF readers for DOS \| XPDF 3.02pl5 - 2010-Oct-21 Post reply
	> > 4+1/2 years after 3.02, XPDF 3.03 is out (untested) BTW, it's not that old, the pl5 ("patchlevel 5") build is dated from October 2010, so that's less than a year ago. > Anyways, I've already grabbed 3.02pl5 recently, so I should just mirror > that for us later tonight (iBiblio only has 3.02pl1). http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/xpdf/

DOS386

19.08.2011, 03:36

@ Rugxulo

PDF readers for DOS | XPDF 3.03 more info | Subdocuments

Post reply

> BTW, it's not that old, the pl5 ("patchlevel 5") build is dated from
> October 2010, so that's less than a year ago.

The "pl" stuff IIRC has just useless subsubsubsubsubsubminor changes at best :-(

> > Anyways, I've already grabbed 3.02pl5 recently, so I should just mirror
> > that for us later tonight (iBiblio only has 3.02pl1).
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/xpdf/

Done! ("pl1" deleted, don't forget to update FB and FASM too) :-)

What's new in 3.03 :

* http://www.foolabs.com/xpdf/CHANGES (huuuuuuuuuuuuge list)
* deleted bloated, obsolete and useless DGJPP binaries
* added bloated, obsolete and useless Win64 binaries
* added PDFDETACH.EXE tool - now can extract subdocuments in DOS

I wrote (2011-03-01) :

> http://jafile.com/uploads/dos386/pdfoct23.pdf (15 MiB)
> Any technology to extract subdocuments except Sumatra (added in 1.2,
> can view and even save them) ?
> > 1.2 (2010-11-26):
> > Changes in this release:
> > open embedded PDF documents
> > allow saving PDF document attachements to disk

YES - XPDF 3.03 can (3.02pl5 can't) :-)

BTW, the new 3.03 Win32 binaries do work well with HX - so I don't need the DGJPP binaries badly ... CPU compatibility not tested (CMOVNTQ&Co) :-|

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

Rugxulo

Usono,
19.08.2011, 05:59

@ DOS386

PDF readers for DOS | XPDF 3.03 more info | Subdocuments

Post reply

> > BTW, it's not that old, the pl5 ("patchlevel 5") build is dated from
> > October 2010, so that's less than a year ago.
>
> The "pl" stuff IIRC has just useless subsubsubsubsubsubminor changes at
> best :-(

Well, it was still a recompile for DOS, so ... honestly, maybe he was unable (for some technical reason) to build latest version with DJGPP, who knows.

> > > Anyways, I've already grabbed 3.02pl5 recently, so I should just
> mirror
> > > that for us later tonight (iBiblio only has 3.02pl1).
> > http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/xpdf/
>
> Done! ("pl1" deleted, don't forget to update FB and FASM too) :-)

I didn't actually delete "pl1", but the way things are currently set up, I moved it to "old", which for whatever reason doesn't show up (and won't let me fix it either, blech). Well, honestly, who needs it? :-P

> BTW, the new 3.03 Win32 binaries do work well with HX - so I don't need the
> DGJPP binaries badly ... CPU compatibility not tested (CMOVNTQ&Co) :-|

Lucky ... usually things never work for me. Too bad more Win32 people don't test more with HX (esp. when dropping DJGPP).

KormaX

01.11.2017, 00:51

@ Rugxulo

PDF readers for DOS | XPDF 3.03 more info | Subdocuments

Post reply

For the honour of DOS!

If anybody is still interested, I am using this tool to view PDF-s on DOS:
http://www.nomdo.dds.nl/psview.htm

It is actually a controller to PDF2PS, GhostScript and LXPIC in order to convert .PDF to a temporary postscript file, than converting it to temporary .PCX pictures and than displaying them in LXPIC. It works fine, but I use it with a batch script placing all the components into a RAM-disk so no real disk read-write stuff happens after "loading" all the stuff once. Also thanks for the Arachne packages, most of the links stille works so I downloaded a lot of them to try :D

---
DOS isn't about why. It's about why not.

PDF readers for DOS (Users)

PDF readers for DOS

PDF readers for DOS

PDF readers for DOS

PDF readers for DOS

Tested PDFTK,,, *and* MUPDF with HX

Tested PDFTK,,, *and* MUPDF with HX

Tested PDFTK,,, *and* MUPDF with HX

Tested PDFTK,,, *and* MUPDF with HX

MUPDF with HX | MUPDF with DGJPP | XPDF without FONTS

MUPDF with HX | MUPDF with DGJPP | XPDF without FONTS

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release! CRTC.CFG

MUPDF/DGJPP test release! CRTC.CFG

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release! SHOTS

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release! | progress, LFB, evil PDF 1.7

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MTRRLFBE -Good news !

MTRRLFBE -Good news !

more insight into BIOS MTRRs

more insight into BIOS MTRRs

more insight into BIOS MTRRs

more insight into BIOS MTRRs

more insight into BIOS MTRRs

more insight into BIOS MTRRs

more insight into BIOS MTRRs

more insight into BIOS MTRRs

more insight into BIOS MTRRs

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release!

MUPDF/DGJPP test release | missing PDFDRAW.EXE | source cod

MUPDF/DGJPP test release | missing PDFDRAW.EXE | source cod

MUPDF/DGJPP test release | missing PDFDRAW.EXE | source cod

MUPDF/DGJPP test release | missing PDFDRAW.EXE | source cod

MUPDF/DGJPP test release | missing PDFDRAW.EXE | source cod

MUPDF/DGJPP test release | missing PDFDRAW.EXE | source cod

MUPDF/DGJPP test release | missing PDFDRAW.EXE | source cod

Tested PDFTK,,, and MUPDF with HX

Tested PDFTK,,, and MUPDF with HX

Tested PDFTK,,, and MUPDF with HX

Tested PDFTK,,, and MUPDF with HX