convert pdf to bmp

[DiTBho]

I need a tool to convert pdf into bmp but able to have a predefined width and height.
I mean I need to have bmp of 1024 x768, and I need to script it.

I have a list of pdf and I need to process them automatically, so I need a tool that works on a text console, and can be invoked by bash.

[SiliconWizard]

I think the tool you're looking for - especially if you want a CLI tool - is imagemagick.

For PDF support, you also need to install Ghostscript. Then imagemagick should be able to do exactly what you want.

https://imagemagick.org/

[DiTBho]

I will check, Imagemagick has a dedicated "postscript" flag.
Thanks for the tips! 

[Nominal Animal]

I like to use pdftoppm (from poppler-utils) instead.  Of course, the output is then not bmp but ppm, but netpbm (ppmtobmp) can fix that.  netpbm (pnmquant) can also do a pretty good job of quantizing the image to indexed color formats (to save RAM needed).

For your use case, pdftoppm does have -scale-to-x and -scale-to-y parameters, with -1 meaning "keep aspect ratio"; and -cropbox for using the PDF crop box area instead of full media area.

If you want or need to, you can compile a minimal version of poppler to cater to just your own needs; the LinuxFromScratch Poppler page will help with that.  For NetPBM, use the Advanced branch.

[PKTKS]

Can handle multiple pages organized cropped scaled and rotated..

Code: [Select]

>mutool draw  -o <out>.png <input>.pdf  &&  convert -size 1024x768  <out>.png <out>.bmp


Paul

[DiTBho]

mutool

Thanks! I will evaluate MuPDF too!

[DiTBho]

I am compiling Poppler, and I have notied it has support for:
splash output
cairo output
abiword output


I don't need abiword, but I don't know if I need Cairo.
Cairo is not currently installed and it needs a lot of libraries.

[PKTKS]

mupdf is all ghostscript based, expect closer results

Paul

[DiTBho]

mupdf is all ghostscript based, expect closer results

Compiled! It works great, and it's lighter.
It can be compiled with support for SVG, but this way it requires Cairo

[PKTKS]

mupdf is all ghostscript based, expect closer results

Compiled! It works great, and it's lighter.
It can be compiled with support for SVG, but this way it requires Cairo

Yep lighter and with better rendering...

Just for curiosity:  Why would you prefer to use such a crappy BMP
instead of JPG format ?

A simple run here of a complex pdf resulted in 16 times bigger results... 

Code: [Select]

-rw-rw-----  1 me host  1505634 Jan 22 07:51 _x.bmp
-rw-rw-----  1 me host    92087 Jan 22 07:51 _x.jpg


A hell of a crappy format...

Paul

[PKTKS]

I am not aware of this dependency... 

Mine is full featured and it is not linked to GTK by any means

Code: [Select]

>ldd mutool
        libm.so.6 => /lib/libm.so.6 (0xb7eaa000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7e8e000)
        libc.so.6 => /lib/libc.so.6 (0xb7ce2000)
        /lib/ld-linux.so.2 (0xb7ef1000)

But obviously ....   *UNLIKE*  the potterix systemd wayland thingy...

A full properly installed X server must be  operational.. and..
Not crippled by default as it comes on those potterix  distros..

Code: [Select]

>ldd mupdf
        libGL.so.1 => /lib/libGL.so.1 (0xb7ef0000)
        libX11-xcb.so.1 => /usr/X11/lib/libX11-xcb.so.1 (0xb7b4d000)
        libX11.so.6 => /usr/X11/lib/libX11.so.6 (0xb7d89000)
        libXau.so.6 => /usr/X11/lib/libXau.so.6 (0xb7aed000)
        libXdamage.so.1 => /usr/X11/lib/libXdamage.so.1 (0xb7b54000)
        libXdmcp.so.6 => /usr/X11/lib/libXdmcp.so.6 (0xb7ae6000)
        libXext.so.6 => /usr/X11/lib/libXext.so.6 (0xb7b17000)
        libXfixes.so.3 => /usr/X11/lib/libXfixes.so.3 (0xb7b4f000)
        libXrandr.so.2 => /usr/X11/lib/libXrandr.so.2 (0xb7d7f000)
        libXrender.so.1 => /usr/X11/lib/libXrender.so.1 (0xb7aa9000)
        libXxf86vm.so.1 => /usr/X11/lib/libXxf86vm.so.1 (0xb7b29000)
        libc.so.6 => /lib/libc.so.6 (0xb7bd2000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7ab3000)
        libdrm.so.2 => /lib/libdrm.so.2 (0xb7ad4000)
        libexpat.so.1 => /lib/libexpat.so.1 (0xb7baa000)
        libglapi.so.0 => /lib/libglapi.so.0 (0xb7b57000)
        libm.so.6 => /lib/libm.so.6 (0xb7f53000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7ab8000)
        libxcb-dri2.so.0 => /usr/X11/lib/libxcb-dri2.so.0 (0xb7b2e000)
        libxcb-dri3.so.0 => /usr/X11/lib/libxcb-dri3.so.0 (0xb7ba6000)
        libxcb-glx.so.0 => /usr/X11/lib/libxcb-glx.so.0 (0xb7b34000)
        libxcb-present.so.0 => /usr/X11/lib/libxcb-present.so.0 (0xb7ba3000)
        libxcb-randr.so.0 => /usr/X11/lib/libxcb-randr.so.0 (0xb7b93000)
        libxcb-render.so.0 => /usr/X11/lib/libxcb-render.so.0 (0xb7b7e000)
        libxcb-shape.so.0 => /usr/X11/lib/libxcb-shape.so.0 (0xb7b7b000)
        libxcb-sync.so.1 => /usr/X11/lib/libxcb-sync.so.1 (0xb7b75000)
        libxcb-xfixes.so.0 => /usr/X11/lib/libxcb-xfixes.so.0 (0xb7b8b000)
        libxcb.so.1 => /usr/X11/lib/libxcb.so.1 (0xb7af0000)
        libxshmfence.so.1 => /usr/X11/lib/libxshmfence.so.1 (0xb7b73000)
        /lib/ld-linux.so.2 (0xb7f9a000)

Paul

[DiTBho]

Why would you prefer to use such a crappy BMP instead of JPG format ?

I need BMP, it's used at the low level and I don't have the ROM-space for a jpeg decompressor.

[rs20]

A hell of a crappy format...

Good grief, there's more to a format than just whether or not it features compression...

[cavac]

A hell of a crappy format...

Good grief, there's more to a format than just whether or not it features compression...

I agree. And sometimes, compression is a hinderance, not only because of compression artifacts. For example, you could extract pixels from a raw image buffer or an uncompressed BMP on something like an Arduino. But if you have JPG, you are pretty much screwed.

And, oh, the BMP format supports run-length compression - just nobody uses it, because some programs don't support it. If you have strictly black&white stuff like text and line graphics, you can use the 1 bit per pixel mode with RLE and get quite small files - lossless!

[DiTBho]

if you have JPG, you are pretty much screwed.

Yup. Especially if you need to implement things in assembly because you are hacking a PDA that Sharp doesn't like you to hack

I like BMP also because I have simple and light support in SDL, I used to it to make some preliminary consideration on a more comfortable RPI SBC. PNG has support, but it takes much more space.

I have implemented a simple bmp image-show function in assembly, able to directly shows bmp images on the video-ram to save space in the rom because at Sharp they are not hacker-friendly with some of their products.

I have more than 16Mbyte of flash, but it's all hardware protected, you need "high voltage" to unlock pages in order to reprogram them, only page1 and page2 are unprotected, so I can only reprogram  512Kbyte of flash, and in this space I have to implement a bootloader with tftpboot support, an elf loader, and a very basic graphical menu.

Oh, don't you guess what's inside page 0? The Sharp logo, in BMP format: unfortunately it cannot be erased. When you switch it on It shows the logo, then it jumps into page1

[PKTKS]

(..)
Oh, don't you guess what's inside page 0? The Sharp logo, in BMP format: unfortunately it cannot be erased. When you switch it on It shows the logo, then it jumps into page1

Well  in your case I would just use an embed logo in the code itself.

BitBlt the struct pointer directly to VRAM would waste just the necessary struct
data ( usually hosted in the program data area ).

I would dump any dependency upon format or containers and go
straight to "IN_program" logos...

Just check required space... it should be reasonably fine with common logos
in large backgrounds...(which you can do by BitBlt screening)

Paul

[DiTBho]

Well  in your case I would just use an embed logo in the code itself.

I don't need to show the original SHARP logo, I need to show some minimal icons for my graphical interface, some buttons to be pressed to to choose what to boot 

It's a kind of Grub with a touchscreen and icons, and it only bootstrap from the network.

Linux is one of the things I'd like to bootstrap, and in this case again I will re-use part of my framebuffer-BMP library to show PDF-to-BMP converted pages; the alternative is SDL-v1, which is ok and it has native support for BMP images, but I don't like it too much.

The final application is a Kind of ebook-reader made on a hacked Japanese PDA. Just for fun, the Remarkable2 is light years ahead more powerful, precise, fast, and practical than this toy, but it costs 600 euro including postage  and customs fees.

There is a similar application inside the ROM, but it's in Japanese language and I am not able to use it

[cavac]

Especially if you need to implement things in assembly because you are hacking a PDA that Sharp doesn't like you to hack

Legally, you wanted to say "Reverse-engineer and update and improve a privately owned device for which the manufacturer does not provide adequate support in order to provide a longer lifetime and protect the environment", i presume? 

[DiTBho]

Legally, you wanted to say "Reverse-engineer and update and improve a privately owned device for which the manufacturer does not provide adequate support in order to provide a longer lifetime and protect the environment", i presume? 

Yup. It's a 2003 device, no longer on sale since 2009, and it would a shame to throw it away