>penguin would shrink the result to fit its screen.
>I declared A5 and Letter paper, media type stationery, and an output bin called face-up.
You can (and should!) define exact dimensions of your screen in `media-size-supported`. It will probably be a non-standard IPP name, that's why you should define that in `media-supported` as `om_NNNmmxYYYmm` or `oe_NNNinxYYYin`
That way you don't need to scale the incoming data, the PC will format it exactly to the dimensions of the screen.
Both PWG Raster and Apple Raster support 1-bit-per-pixel mode (instead of 8-bit-per-pixel you use), that's why the input could be 8 times less in size. Use `print-color-mode-{supported,default}=bi-level` instead of `monochrome` for that. And also tune `urf-supported`'s `W` option, use `W1` for this case.
This is why I like it here. Somebody does irrefutably incredible work outside of their comfort zone, and somebody else goes "yeah actually I was born in that zone. Moulded by it. Here's how to improve it" (in a positive way)
Oh no, I wasn't, and that's definitely not my comfort zone. I mess with the printers and printing stack due to anger, not because I like it.
It's bugs on bugs, with bugs chasing bugs! So little developers, so complex stack with 25 years of technical debt, and little community around because it's not a sexy technology to be involved in.
That's why I have to dive deep and fix my bugs myself if I want to make it work properly as I would like it to. I also ended up making my own print server device, because China did not make a proper one for some reason for all these years.
This thread made me laugh. I worked on network printing software in Banyan VINES a century or two ago, and my wife always wondered why I hated printing software so much. Everything about the printing software stack, especially in Windows, is terrible.
Very cool. I was expecting to learn about the ins and outs of ink, printheads etc but instead learned "How to build a paper that acts like a printer" which turned out much more entertaining.
This is called a 'plotter', there's a whole community of axi-draw enthusiasts making cool art, for 200 bones you can probably have one on your doorstep tomorrow
One of the great things about having an open platform like the Xteink is that it should uncover loads of novel and unsatisfied use cases. Eg, this could be paired with a mobile phone to act as a secondary display much better suited to outdoor applications in bright sunlight.
working on an daily life ePub generator (because I want to stick to CrossPoint) with the opposite goal, namely use the phone as little as possible, but I admit I would also like to tinker with an additional temporary display, at least for typing
In Linux it's pretty easy to create such things with cups. A while ago I did a cups backend for my Fujitsu Quaderno A4 [1]. It is super useful to be able to just open any document, in any program that supports printing, and then just "print" it to my device.
Unfortunately printing support seems to go out of fashion, at least in macOS land.
Lately I needed a quick printout of a markdown document. I could have used TextEdit for the raw text, but I wanted the styling too. Learned that neither VSCode, Xcode nor Obsidian can print. (There is a community plugin for Obsidian.)
I think back in the days before office workers that happened to do their work on a computer had access to the ancient relatives of "Microsoft Word"/"Libreoffice Writer", it was pretty normal for printers to take care of plain text files, with about as much fidelity as manual operation of a classic purely mechanical Typewriter.
Since then printers progressively forgot how to cope with such "documents", though IIRC good-old HP "PCL" should only require about a bare minimum of framing/job control to get a modern printer to handle ASCII plain text.
> printing has never really been a thing from text editors I think.
It's always been a thing: We programmed on paper before we had screen editors, and so early screen editors have always had a way to murder trees on demand:
In vi it's :ha
In emacs it's M-x print-buffer
> It has been a while since I printed a plain text file, but I guess there's still a similar command available with some research.
`lp myfile.txt`
I still prefer using hardcopy for reading/debugging.
I used to print a lot of code from Geany, that has some nice support for printing line numbers and code highlights that I have a hard time replicating in other tools.
I see that it applies styles to markdown documents, but keeps all formatting characters visible (e.g. # for titles). I guess I wasn't happy with that and looked for another solution.
How is that open source? There’s not a single line of code. No CAD. Nothing. Sure, there’s a “coming soon” CrowdSupply link, which I guess is more than a KickStarter. But open source?
Fair enough but I trust CrowdSupply to keep them in check. I bought quite a few projects via CS and never been disappointed. They have too much trust from the community not to follow up, it's their most important differentiator versus KickStarter and other crowdfunding platforms.
I have had a daisy wheel printer project on the back burner for a while. They where never sold much where I live or are just very difficult to come by in usable condition. Figured it would be doable to create with a 3d printer and some simple electronics.
Inkjet is quite difficult but dot matrix printers are easier to find DIY projects of.
Pretty cool work! And it’s nice to see printer discovery works through the standard mDNS!
Regarding the size of the page being sent to the printer, I remember reading that printers used to be postscript interpreters and the result of that program would be the page.
Perhaps that would trade ram for compute, but might be more complex in the end.
Exactly. Anytime you can leverage a universal OS protocol, you instantly bypass the proprietary gatekeepers. Building on open standards is always the smarter architectural play.
For fast updates / high frame rate, especially also smooth fade from previous to next page, those displays only do black/white.
They can typically modulate about 14 levels of gray in-between but reliably (without really bad ghosting, due to strong temperature sensitivity of the pixel's transition response and the display being static so all gray has to be done by carefully interrupting a transition part way through) only from a nice flash-to-black -> flash-to-white -> fade-to-target-greyscale (sometimes one or two alternating full contrast flashes prepended to more intensely equalize the pixels/erase ghosting, but should only be needed every couple dozen page flips in grayscale mode).
I think the nice b/w no-flicker fade transitions chop the transitioning of all changing pixels into small burst/chunks and interleave/alternate the chunks of white-to-black with the chunks of black-to-white, so it's perceptually simultaneous.
Or it's actually pulling off some kind of tri-state driving leaving unchanging pixels alone and pulling those that change to either plus or minus polarity depending on what transition direction they are supposed to go in...
Sadly IIRC all quite proprietary-gated :(
What that means for djvu is that at least for text-only content on those readers that manage the 300 dpi "threshold" you'd just rasterize to pure 300dpi black/white (1 bit per pixel) comparable to a 300dpi "don't skimp on toner but don't you dare take half a second longer than you must in order to make the text crisp enough for $reader to have no good reason to whine about it being not crisp enough" laser printer job.
Djvu is particularly for displays with more than about 5bits of grayscale as well as for lossy compression of grayscale/color scans. And maybe also some efficiency gains on 1-bit-per-pixel quantized scans, but those aren't usually the target content for these readers, IMO.
Might want to try for them, though!
Hm.. I just tried on my Google pixel 7 Pro (obviously very different display - OLED) - and certainly seems like the result of a test conversion pdf2djvu should be at home on an eink screen. Not sure if there's a simple way to test on the only eink I have to hand; a Remarkable.
Fwiw google Gemini cane up with the following to convert pdfs on device in termux after some prodding (koreader can display DjVu):
You'll need access to storage:
termux-setup-storage
Then pipe/paste this to a script:
(Sorry for the verbose slop)
You can just render to the 1bpp text/4bpp images monochrome 300dpi target; perhaps some tone mapping due to the limited contrast ratio of the eink vs. your OLED should be done at rasterization time.
Then just map the resulting 16 brightness levels according to the contrast ratios/progression they have on your eink. Use phone camera and adjust whole image contrast/brightness/black-intensity sliders holding them side by side until the grayscale matches.
Then just pick pixel RGBs from a gray-bars test image you have opened on the remarkable before you took the picture with your pixel 7 pro. Might not easily be done on the phone but can let a python using AI grab those for you. (If it's wrong it'll be obvious or so harmless it doesn't matter anyways.)
Then you take that rasterized-to-1/4-bpp-djvu apply the color palette you just built yourself, and zoom to 300dpi.
Other than the screen backlight which you've taken care of when you held both devices side-by-side and played with the sliders, there's no substantial difference left.
Should be pretty representative.
Don't look with too much of a magnifying glass though the phone doesn't have exactly the same dpi so there are resampling artifacts your eyes resolve if you're too close to it.
I've been seeing the Xteink a lot lately. Should I get an X3 or an X4? I don't really know why I want it, but I have an eInk addiction, so I just need it.
I bought an x4 a month or so ago, zero regrets. It sounds hyperbolic but it’s finally been the thing to actually decouple me from my phone. Whenever I’m out and about, bored, I just slide it out and pick up where I left off reading last. It’s a nicer reading experience on my kobo but the portability and.. frankly charm just can’t be beat.
I did open the thread and didn't see an actual printer shown except the e-ink device but aside from that, I hate printers buy a cartridge it's empty after 3 prints wtf... now I just go walk into some store like Walgreens to print stuff
For me my favorite is the RM2 but I keep selling/buying it back due to poor financial decisions but I love how it writes and long battery, plus hackable, never paid for a subscription. It is an extra device too so unfortunately not used that often I spend most of my time in front of a desktop but have multiple laptops too/drawing tablets.
My 10 year old mono laser printer requires a cartridge very two years or so. This is despite being a lot more heavily used than the average domestic printer.
I got my laserjet secondhand 10 years ago. It was already 10 years old at this time. It's been low on toner since the beginning but shaking the toner cartridge is usually enough to get usable prints the few times a year I need it (return labels, letters). It's a great, reliable device!
I was thinking of this, but rendering PDF takes a lot out of a 400KB RAM'd device. It also needs a ton of things to actually work which the ROM can't hold.
PDF is very, very complicated standard which can't be handled properly on tiny MCUs with reasonable performance and spec conformance:
- 4 font formats
- 9 image formats
- blending with transparency
- different colorspaces, each image could use its own on the page
- different dithering algorithms, each image with its own
- the page can have elements from another pages (global elements)
This is only a small part from the top of my head.
Common simple home printers absolutely should not accept regular PDF as an input: thanks to Apple and IETF we now have Apple Raster and PWG Raster for printers, as a part of AirPrint and IPP Everywhere/Mopria driverless printing standards, which are very similar but have slightly different options and headers. It's a simple raster input for printers specifically.
Some companies, such as HP, invented a "raster PDF": PCLm / PCLms. Don't be confused by the name, it's a regular standard-conforming PDF which contain nothing but a full-page JPEG on each page, and don't use any other features. It's created only to be able to open "printed page" (driver output) in a standard PDF viewer on a PC for debugging or business logging needs, but otherwise it's like a regular JPEG with additional per-page metadata.
That's weird, the product page says "TXT, EPUB, MOBI, PDF, JPG, PNG" and prominently claims it is good for manga, which definitely wouldn't be possible with those formats.
Just open pdf on mac, hit print, grab a kindle and there it is (yes, I know, we can do send to kindle, and some time later, when Jeff Bezos allows so, the doc might appear).
> I was thinking of this, but rendering PDF takes a lot out of a 400KB RAM'd device. It also needs a ton of things to actually work which the ROM can't hold.
I've wanted something like this for a long time to print recipes that I'm about to cook. I don't want my phone in the kitchen getting gunk on it, so I'll usually print on paper, get the gunk on the paper, and then throw it out.
I'm not going to create a recipe PDF and load it on an e-reader. That's too much work. But I will happily press control-P on a recipe web page and select the eink display as the target.
I'd like my e-reader to show up as a printer, and when I print something on it it actually gets saved as a pdf on the reader. Like in the article, but multi-page pdf.
I often do 'print to A5 pdf => copy pdf to e-reader'. Would be nice to do that in one step from any program that can print.
>penguin would shrink the result to fit its screen. >I declared A5 and Letter paper, media type stationery, and an output bin called face-up.
You can (and should!) define exact dimensions of your screen in `media-size-supported`. It will probably be a non-standard IPP name, that's why you should define that in `media-supported` as `om_NNNmmxYYYmm` or `oe_NNNinxYYYin`
That way you don't need to scale the incoming data, the PC will format it exactly to the dimensions of the screen.
Both PWG Raster and Apple Raster support 1-bit-per-pixel mode (instead of 8-bit-per-pixel you use), that's why the input could be 8 times less in size. Use `print-color-mode-{supported,default}=bi-level` instead of `monochrome` for that. And also tune `urf-supported`'s `W` option, use `W1` for this case.
The screen/dithering could be ass in 1-bit mode, see https://github.com/OpenPrinting/libcupsfilters/pull/160 where I added more dithering options (Linux-only though, Apple seems to abandon their CUPS).
lovely, this would save me a bunch of memory during transformation and dithering. Will do!
This is why I like it here. Somebody does irrefutably incredible work outside of their comfort zone, and somebody else goes "yeah actually I was born in that zone. Moulded by it. Here's how to improve it" (in a positive way)
Oh no, I wasn't, and that's definitely not my comfort zone. I mess with the printers and printing stack due to anger, not because I like it.
It's bugs on bugs, with bugs chasing bugs! So little developers, so complex stack with 25 years of technical debt, and little community around because it's not a sexy technology to be involved in.
That's why I have to dive deep and fix my bugs myself if I want to make it work properly as I would like it to. I also ended up making my own print server device, because China did not make a proper one for some reason for all these years.
That's even cooler
Same feeling when family or friends ask me for help with Micros word about formatting, tables or inserting pictures in the last 25 years….
Anger is the only valid emotion when dealing with printers.
PC Load Letter?
This thread made me laugh. I worked on network printing software in Banyan VINES a century or two ago, and my wife always wondered why I hated printing software so much. Everything about the printing software stack, especially in Windows, is terrible.
The law requires to mention the outstanding documentation “Office Space“ here.
Hey sadly this stuff doesn't ask for consent when it makes you an expert. Everybody hates printers, only a few make their own print server device
> Use `print-color-mode-{supported,default}=bi-level` instead of `monochrome` for that
The last time I checked (a year ago), 1bpp was suddenly supported only by Windows. IIRC, monochrome is REQUIRED, while bi-level is OPTIONAL in RFC.
Not sure how things stand now, though. Ever since then, I've just been carrying Floyd–Steinberg dithering around.
Very cool. I was expecting to learn about the ins and outs of ink, printheads etc but instead learned "How to build a paper that acts like a printer" which turned out much more entertaining.
glad you liked it!
Wanted ideas on how to build an ink printer that is untraceable. For privacy reasons.
I wonder why we don't see slow-but-actually-works approaches that reuse 3d-printer hardware
just put a pen or sharpie on the same mechanism, no?
This is called a 'plotter', there's a whole community of axi-draw enthusiasts making cool art, for 200 bones you can probably have one on your doorstep tomorrow
And it's been a thing wayyyyyy before 3D printers were even a twinkle in some engineers eye
Alas, you might have to make do with a dot-matrix printer at draft quality.
Good article.
One of the great things about having an open platform like the Xteink is that it should uncover loads of novel and unsatisfied use cases. Eg, this could be paired with a mobile phone to act as a secondary display much better suited to outdoor applications in bright sunlight.
working on an daily life ePub generator (because I want to stick to CrossPoint) with the opposite goal, namely use the phone as little as possible, but I admit I would also like to tinker with an additional temporary display, at least for typing
> open platform like the Xteink is that it should uncover loads of novel and unsatisfied use cases
+1.
And it's worth celebrating the underlying technologies that enable this: ESP32, and RISC-V.
Anyone know what's needed for eink to become cheaper?
In Linux it's pretty easy to create such things with cups. A while ago I did a cups backend for my Fujitsu Quaderno A4 [1]. It is super useful to be able to just open any document, in any program that supports printing, and then just "print" it to my device.
[1] https://github.com/cristobaltapia/dpt-rp1-cups
> any program that supports printing
Unfortunately printing support seems to go out of fashion, at least in macOS land.
Lately I needed a quick printout of a markdown document. I could have used TextEdit for the raw text, but I wanted the styling too. Learned that neither VSCode, Xcode nor Obsidian can print. (There is a community plugin for Obsidian.)
LOL. TIL you can’t print from VSCode.
Or Obsidian
printing has never really been a thing from text editors I think.
Used to be that printing a text file was just `cat myfile.txt > /dev/lp0` .
It has been a while since I printed a plain text file, but I guess there's still a similar command available with some research.
I've done the same from a raspberry pi to a receipt printer, just piping to lp0
TextEdit.app supports printing, so does Notepad.exe (unless they removed that recently).
vim/nvim at least have :print
I think back in the days before office workers that happened to do their work on a computer had access to the ancient relatives of "Microsoft Word"/"Libreoffice Writer", it was pretty normal for printers to take care of plain text files, with about as much fidelity as manual operation of a classic purely mechanical Typewriter.
Since then printers progressively forgot how to cope with such "documents", though IIRC good-old HP "PCL" should only require about a bare minimum of framing/job control to get a modern printer to handle ASCII plain text.
> printing has never really been a thing from text editors I think.
It's always been a thing: We programmed on paper before we had screen editors, and so early screen editors have always had a way to murder trees on demand:
In vi it's :ha
In emacs it's M-x print-buffer
> It has been a while since I printed a plain text file, but I guess there's still a similar command available with some research.
`lp myfile.txt`
I still prefer using hardcopy for reading/debugging.
> printing has never really been a thing from text editors I think.
there's literally ctrl+p shortcut for printing
I used to print a lot of code from Geany, that has some nice support for printing line numbers and code highlights that I have a hard time replicating in other tools.
Fairly sure you can netcat asci on port 9100 to HP Jet Direct printers still.
Edit:
This one seems to work well: pdconsec.vscode-print
Link: https://marketplace.visualstudio.com/items?itemName=pdconsec...
And of course it just renders an HTML document (applies some CSS to the text content) and then uses the embedded browser's printing.
Xcode should have printing capabilities. 26.6 does on my system anyway.
You're right. I mis-remembered it.
I see that it applies styles to markdown documents, but keeps all formatting characters visible (e.g. # for titles). I guess I wasn't happy with that and looked for another solution.
That is much fewer LoC than I expected.
How is "offline e-reader" handled? Does CUPS retry?
Do you do this outside of your LAN?
Good job, but I’m left wanting to know how to build a printer.
I'd say it's an eco-friendly printer
If a DIY plotter would do, this site has a long list of different projects
https://mattwidmann.net/notes/pen-plotters/
What if I want a cabinet sized rotating head printer that can print carbonpaper triplets, sounds a machinegun, and has LP0 ON FIRE error message
There is an open source one https://www.opentools.studio
How is that open source? There’s not a single line of code. No CAD. Nothing. Sure, there’s a “coming soon” CrowdSupply link, which I guess is more than a KickStarter. But open source?
Ah sorry, I thought they were already open source. They say they will open source it once they finalize the design, but yeah, not there yet.
Fair enough but I trust CrowdSupply to keep them in check. I bought quite a few projects via CS and never been disappointed. They have too much trust from the community not to follow up, it's their most important differentiator versus KickStarter and other crowdfunding platforms.
As far as I can remember, framework has this still on their schedule. So sooner or later you maybe can at least have a well maintainable one.
I have had a daisy wheel printer project on the back burner for a while. They where never sold much where I live or are just very difficult to come by in usable condition. Figured it would be doable to create with a 3d printer and some simple electronics.
Inkjet is quite difficult but dot matrix printers are easier to find DIY projects of.
This would be a neat API for a digital photo frame - just print photos to it and they appear on the screen.
yes!!
And then maybe different pages become a slideshow.
Pretty cool work! And it’s nice to see printer discovery works through the standard mDNS!
Regarding the size of the page being sent to the printer, I remember reading that printers used to be postscript interpreters and the result of that program would be the page.
Perhaps that would trade ram for compute, but might be more complex in the end.
Emulating a network printer to send pages to an e-ink screen is such a clever hack. Every OS already has the print dialog built in.
Just like print-to-pdf is (one of many) peeves of adobe's
Exactly. Anytime you can leverage a universal OS protocol, you instantly bypass the proprietary gatekeepers. Building on open standards is always the smarter architectural play.
This is amazing!!! It just makes sense. And its just how you would want to use a e reader.
if it looks like a paper, it should act like a paper
You can even fold it, once!
It's also not effective against rock
Funny. But... paper covers rock.
Jan Ken Po!
Nice. I keep wondering if these devices would play nicer with DjVu rather than pdfs and raster formats?
https://djvu.sourceforge.net/
For fast updates / high frame rate, especially also smooth fade from previous to next page, those displays only do black/white. They can typically modulate about 14 levels of gray in-between but reliably (without really bad ghosting, due to strong temperature sensitivity of the pixel's transition response and the display being static so all gray has to be done by carefully interrupting a transition part way through) only from a nice flash-to-black -> flash-to-white -> fade-to-target-greyscale (sometimes one or two alternating full contrast flashes prepended to more intensely equalize the pixels/erase ghosting, but should only be needed every couple dozen page flips in grayscale mode).
I think the nice b/w no-flicker fade transitions chop the transitioning of all changing pixels into small burst/chunks and interleave/alternate the chunks of white-to-black with the chunks of black-to-white, so it's perceptually simultaneous. Or it's actually pulling off some kind of tri-state driving leaving unchanging pixels alone and pulling those that change to either plus or minus polarity depending on what transition direction they are supposed to go in... Sadly IIRC all quite proprietary-gated :(
What that means for djvu is that at least for text-only content on those readers that manage the 300 dpi "threshold" you'd just rasterize to pure 300dpi black/white (1 bit per pixel) comparable to a 300dpi "don't skimp on toner but don't you dare take half a second longer than you must in order to make the text crisp enough for $reader to have no good reason to whine about it being not crisp enough" laser printer job.
Djvu is particularly for displays with more than about 5bits of grayscale as well as for lossy compression of grayscale/color scans. And maybe also some efficiency gains on 1-bit-per-pixel quantized scans, but those aren't usually the target content for these readers, IMO. Might want to try for them, though!
Hm.. I just tried on my Google pixel 7 Pro (obviously very different display - OLED) - and certainly seems like the result of a test conversion pdf2djvu should be at home on an eink screen. Not sure if there's a simple way to test on the only eink I have to hand; a Remarkable.
Fwiw google Gemini cane up with the following to convert pdfs on device in termux after some prodding (koreader can display DjVu):
You'll need access to storage:
termux-setup-storage
Then pipe/paste this to a script: (Sorry for the verbose slop)
Ed: moved to sibling comment
You can just render to the 1bpp text/4bpp images monochrome 300dpi target; perhaps some tone mapping due to the limited contrast ratio of the eink vs. your OLED should be done at rasterization time.
Then just map the resulting 16 brightness levels according to the contrast ratios/progression they have on your eink. Use phone camera and adjust whole image contrast/brightness/black-intensity sliders holding them side by side until the grayscale matches.
Then just pick pixel RGBs from a gray-bars test image you have opened on the remarkable before you took the picture with your pixel 7 pro. Might not easily be done on the phone but can let a python using AI grab those for you. (If it's wrong it'll be obvious or so harmless it doesn't matter anyways.)
Then you take that rasterized-to-1/4-bpp-djvu apply the color palette you just built yourself, and zoom to 300dpi.
Other than the screen backlight which you've taken care of when you held both devices side-by-side and played with the sliders, there's no substantial difference left. Should be pretty representative. Don't look with too much of a magnifying glass though the phone doesn't have exactly the same dpi so there are resampling artifacts your eyes resolve if you're too close to it.
I've been seeing the Xteink a lot lately. Should I get an X3 or an X4? I don't really know why I want it, but I have an eInk addiction, so I just need it.
It's funny that X3 is a successor of X4. Only downside is that X4 has a USB-C port and X3 doesn't
What about the back light? Are they otherwise identical?
X3 isn't backlit, but the battery lasts 7 days. So, it's pretty good for me
I've owned all of them and the answer is the X4 Pro IMO. It has a backlight, which is the only thing I really missed on the others.
I bought an x4 a month or so ago, zero regrets. It sounds hyperbolic but it’s finally been the thing to actually decouple me from my phone. Whenever I’m out and about, bored, I just slide it out and pick up where I left off reading last. It’s a nicer reading experience on my kobo but the portability and.. frankly charm just can’t be beat.
I did open the thread and didn't see an actual printer shown except the e-ink device but aside from that, I hate printers buy a cartridge it's empty after 3 prints wtf... now I just go walk into some store like Walgreens to print stuff
If you like e-ink device reviews this is an artsy channel think small leather notebooks https://www.youtube.com/watch?v=-oOqFUuULOk
For me my favorite is the RM2 but I keep selling/buying it back due to poor financial decisions but I love how it writes and long battery, plus hackable, never paid for a subscription. It is an extra device too so unfortunately not used that often I spend most of my time in front of a desktop but have multiple laptops too/drawing tablets.
My 10 year old mono laser printer requires a cartridge very two years or so. This is despite being a lot more heavily used than the average domestic printer.
Might be a good buy, I don't print much mostly need black and white shipping labels
A mono laser is a good fit for that. The up front cost is higher but the cost per page is tiny.
I got my laserjet secondhand 10 years ago. It was already 10 years old at this time. It's been low on toner since the beginning but shaking the toner cartridge is usually enough to get usable prints the few times a year I need it (return labels, letters). It's a great, reliable device!
I love the concept, but I wonder why he wasn’t printing to PDF. Can this device not render PDFs?
I was thinking of this, but rendering PDF takes a lot out of a 400KB RAM'd device. It also needs a ton of things to actually work which the ROM can't hold.
Kindles have a ton of RAM, this one didn't.
I'm sure there's a super trimmed down linux pdf reader that could be ported over
Probably not. It doesn't appear to have enough ram. I'm not sure the CPU is up to that either.
PDF is very, very complicated standard which can't be handled properly on tiny MCUs with reasonable performance and spec conformance:
This is only a small part from the top of my head.
Common simple home printers absolutely should not accept regular PDF as an input: thanks to Apple and IETF we now have Apple Raster and PWG Raster for printers, as a part of AirPrint and IPP Everywhere/Mopria driverless printing standards, which are very similar but have slightly different options and headers. It's a simple raster input for printers specifically.
Some companies, such as HP, invented a "raster PDF": PCLm / PCLms. Don't be confused by the name, it's a regular standard-conforming PDF which contain nothing but a full-page JPEG on each page, and don't use any other features. It's created only to be able to open "printed page" (driver output) in a standard PDF viewer on a PC for debugging or business logging needs, but otherwise it's like a regular JPEG with additional per-page metadata.
This thing is an e-reader with 16GB of flash and an SD slot. It has native support for PDF.
https://cdn.shopify.com/s/files/1/0759/9344/8689/files/X3-EN...
check page 3. even I was surprised
First I see GIF and PNG missing.
That's weird, the product page says "TXT, EPUB, MOBI, PDF, JPG, PNG" and prominently claims it is good for manga, which definitely wouldn't be possible with those formats.
CrossPoint at least only support ePub and BMP so they could have printed to a directory of BMPs.
That’s where it ends up
I love it! Can we have "print to kindle" now?
Just open pdf on mac, hit print, grab a kindle and there it is (yes, I know, we can do send to kindle, and some time later, when Jeff Bezos allows so, the doc might appear).
Sure, jailbroken Kindles run Linux.
I don't understand the purpose. What am I missing?
The author "prints" to the eink display. Why not load say the pdf directly?
> I was thinking of this, but rendering PDF takes a lot out of a 400KB RAM'd device. It also needs a ton of things to actually work which the ROM can't hold.
> Kindles have a ton of RAM, this one didn't.
It's an e-reader. According to the specs it has native support for PDF.
It's an esp32 MCU, even if it can somehow run the PDF render pipeline, it won't be more ideal than just accept the raw byte stream and display.
From the 4th line in the article:
> But getting stuff onto it was tedious. I had to join its hotspot and open a little upload website in my browser. Yuck.
Anyway, very creative, I like the idea a lot.
I've wanted something like this for a long time to print recipes that I'm about to cook. I don't want my phone in the kitchen getting gunk on it, so I'll usually print on paper, get the gunk on the paper, and then throw it out.
I'm not going to create a recipe PDF and load it on an e-reader. That's too much work. But I will happily press control-P on a recipe web page and select the eink display as the target.
I am no cook, but you my friend are cooking something here
Right! I like this usecase very much. For uses existing software infra to perform the required task.
I wonder now what else we've reinvented when it comes to sending data...
I'd like my e-reader to show up as a printer, and when I print something on it it actually gets saved as a pdf on the reader. Like in the article, but multi-page pdf.
I often do 'print to A5 pdf => copy pdf to e-reader'. Would be nice to do that in one step from any program that can print.
We finally have PADDs from Star Trek!
Wow!! I didn't think of that.
This is a fantastic idea!
Very cool. I'll be updating to this fork
Thanks. It's rough around the edges, so PRs are open, and there's a recipe in the repo if you want to build your own apps.
Outstanding! This is so...correct.
Love this!