Kindle Scribe

[tomsem]

Originally Posted by sgt123456

Wow thanks for the info! I will take a look at it!

It looks like some size reduction is necessary, either by reducing image dimensions or decreasing quality. Not surprisingly, ePub ends up about the same size as the CBZ I used (300MB+), and Send To Kindle has limit of 200MB.

Another option is to convert the KPF file directly to KFX or MOBI ('for old Kindles') directly for side loading.

Kindle Previewer 3 will Export to .mobi (mobi 7). It is considerably smaller but lacks any manga features: it just presents a series of images with manga page turns.

KFX Output plugin will convert KPF to KFX via CLI (it uses command line interface of KP3). There are some limitations to the KFX output (see plugin notes). I was able to convert the large KPF successfully with a 'might be too large for some devices' warning, but Scribe opened it just fine with full manga features.

Calibre conversion of ePub to KF8 succeeds (still 340 MB), the viewer does a reasonable job with it, but Scribe would not open it. Not too surprising. A 'suitably small' KF8 should load okay with full manga features as well.

As I understand it, KFX can be loaded into memory in segments, whereas KF8 has to load all at once.

I have been looking for alternatives to KCC. It does a lot of things I don't want it to do, and doesn't do some others I'd like it to do. I looked at forking the code but it was a mess back then (a year or so ago), and while I had some success in hacking in my feature, I was not happy with the result in the end. Kindle Create does most of what I wanted it to do.

The only problem is Kindle Create has no command line interface, so it is not very amenable to scripting.

[sgt123456]

Originally Posted by tomsem

It looks like some size reduction is necessary, either by reducing image dimensions or decreasing quality. Not surprisingly, ePub ends up about the same size as the CBZ I used (300MB+), and Send To Kindle has limit of 200MB.

Another option is to convert the KPF file directly to KFX or MOBI ('for old Kindles') directly for side loading.

Kindle Previewer 3 will Export to .mobi (mobi 7). It is considerably smaller but lacks any manga features: it just presents a series of images with manga page turns.

KFX Output plugin will convert KPF to KFX via CLI (it uses command line interface of KP3). There are some limitations to the KFX output (see plugin notes). I was able to convert the large KPF successfully with a 'might be too large for some devices' warning, but Scribe opened it just fine with full manga features.

Calibre conversion of ePub to KF8 succeeds (still 340 MB), the viewer does a reasonable job with it, but Scribe would not open it. Not too surprising. A 'suitably small' KF8 should load okay with full manga features as well.

As I understand it, KFX can be loaded into memory in segments, whereas KF8 has to load all at once.

I have been looking for alternatives to KCC. It does a lot of things I don't want it to do, and doesn't do some others I'd like it to do. I looked at forking the code but it was a mess back then (a year or so ago), and while I had some success in hacking in my feature, I was not happy with the result in the end. Kindle Create does most of what I wanted it to do.

The only problem is Kindle Create has no command line interface, so it is not very amenable to scripting.

Yes it seems that KFX with KFX output is the finest way but has some extra steps. There is another option that works fine but it doesn’t use full screen (a little margin is showed), and is to use KCC to delete margins and convert the output to pdf with ACBR wich is super fast doing conversions. Though manga mode and another features are lost.

Anyways it seems its not as easy as in the kobo devices but its not impossible

Thanks!!

[sgt123456]

Hi there !

I have a question about the resolution of sideloaded PDF’s on scribe. When a PDF is so large that you can’t simply send it to kindle with the send-to-kindle feature, I sideload it just plugin a cable and copying it to the scribe filesystem.

Doing this makes opening PDFs at scribe readable with the PDF legacy support that the device has. So it makes little margins (really thin ones) on the document when opened. I don’t mind having those little white margins, but I think the renderer is downscaling the images/pages and it makes little artifacts on words and images. So i was wondering if is there any way to figure out what the resolution of this “window” can be, just to get the PDF rendered like pixel perfect.

I know I can get print replicas with Kindle Create, but I don’t want to mess with this, also I think battery life is better with PDF instead KFX, and I’m not interested in writing on those PDF so don’t need for KFX.

Any thoughts on this ? Thx!

[tomsem]

Originally Posted by sgt123456

Hi there !

I have a question about the resolution of sideloaded PDF’s on scribe. When a PDF is so large that you can’t simply send it to kindle with the send-to-kindle feature, I sideload it just plugin a cable and copying it to the scribe filesystem.

Doing this makes opening PDFs at scribe readable with the PDF legacy support that the device has. So it makes little margins (really thin ones) on the document when opened. I don’t mind having those little white margins, but I think the renderer is downscaling the images/pages and it makes little artifacts on words and images. So i was wondering if is there any way to figure out what the resolution of this “window” can be, just to get the PDF rendered like pixel perfect.

I know I can get print replicas with Kindle Create, but I don’t want to mess with this, also I think battery life is better with PDF instead KFX, and I’m not interested in writing on those PDF so don’t need for KFX.

Any thoughts on this ? Thx!

It seems like the PDFs are scanned images, and fonts are not vectorized as they would be if you generated them from a document. In that case you would not see any pixellation. And converting to PR won't improve the appearance (assuming I understand what you are describing).

That said, Scribe only lets you zoom in so much (PDF or Print Replica).

I just side-loaded a PDF and compared with Print Replica. Functionally PDF support is lacking: page links do not work at all, and the ToC includes an entry for each page in the PDF. The PR version converts the page links perfectly, and converts (multi-level) PDF bookmarks to a nice multi-level ToC. Moreover zoom of PDF leaves white margins, Print Replica uses the full screen.

Given this, I cannot see any advantage to side-loading a PDF.

If PDF is less than 200 MB send to Kindle Web should handle it. There are many free online tools to help reduce file size (including Adobe's).

[Quoth]

Originally Posted by tomsem

Given this, I cannot see any advantage to side-loading a PDF.

1) Privacy for documents that should not be sent to a 3rd party. Such document should never be sent from a gmail account or to a gmail account either.

2) There isn't always Internet available or WiFi.

3) Probably others

[sgt123456]

Originally Posted by Quoth

1) Privacy for documents that should not be sent to a 3rd party. Such document should never be sent from a gmail account or to a gmail account either.

2) There isn't always Internet available or WiFi.

3) Probably others

Yeah… pretty much this. I don’t like to have to send files to where you know where they are going…

[tomsem]

Originally Posted by Quoth

1) Privacy for documents that should not be sent to a 3rd party. Such document should never be sent from a gmail account or to a gmail account either.

2) There isn't always Internet available or WiFi.

3) Probably others

Except the PDF support is really bad.

[BionicGecko]

My wife recently took an interest in the Scribe and has been testing mine out to see how she likes the device, and it seems she has stumbled on what appears to be a fundamental issue with the device.

My wife is left-handed and writes in the typical "claw" style favored by many lefties, i.e. her hand rests on the sheet above the line currently being written (basically to avoid getting ink on her hand). Whenever she writes in her usual way on the Scribe, her hand naturally tends to rest on the top part of the screen, which constantly brings down the top options drawer. This is very disruptive and basically renders the device completely unusable for her.

As far as I know, there is no way to disable the top drawer. Short of re-learning how to write, do you guys know of any solution or workaround to this? The design here seems really short-sighted, seeing that a lot of left-handed people write in this manner.

[NiLuJe]

Despite being right-handed, I learned to write watching left-handed people, so I know the feeling .

In any case, if the pen tip makes contact *before* her pinky finger does, this *should* kick in a global "palm rejection" and ignore everything except the pen (unless somebody at lab126 screwed the pooch). Lifting the pen without lifting the hand should keep behaving after that (again, assuming someone actually thought this through).

Even if it works, that's... not very practical, bit it might be worth a try .

[tomsem]

Originally Posted by BionicGecko

As far as I know, there is no way to disable the top drawer. Short of re-learning how to write, do you guys know of any solution or workaround to this? The design here seems really short-sighted, seeing that a lot of left-handed people write in this manner.

They make writing/drawing gloves that add palm rejection where a device otherwise doesn't provide it. They only go on a couple of fingers and the other fingers and thumb are free.

https://www.amazon.com/Drawing-3-Lay...s%2C175&sr=8-4

[BionicGecko]

Originally Posted by NiLuJe

Despite being right-handed, I learned to write watching left-handed people, so I know the feeling .

In any case, if the pen tip makes contact *before* her pinky finger does, this *should* kick in a global "palm rejection" and ignore everything except the pen (unless somebody at lab126 screwed the pooch). Lifting the pen without lifting the hand should keep behaving after that (again, assuming someone actually thought this through).

Even if it works, that's... not very practical, bit it might be worth a try .

Originally Posted by tomsem

They make writing/drawing gloves that add palm rejection where a device otherwise doesn't provide it. They only go on a couple of fingers and the other fingers and thumb are free.

https://www.amazon.com/Drawing-3-Lay...s%2C175&sr=8-4

Thank you both, those are very good suggestions!

[mergen3107]

Can someone please give an estimate of how much, for example, a 10-page note is in size (megabytes)? I remember someone found out that you can backup these notes since they are saved as PNGs in a system folder.

I am trying to estimate of how much space I’d need in a Scribe (32GB vs 64).

Thanks!

[tomsem]

Originally Posted by mergen3107

Can someone please give an estimate of how much, for example, a 10-page note is in size (megabytes)? I remember someone found out that you can backup these notes since they are saved as PNGs in a system folder.

I am trying to estimate of how much space I’d need in a Scribe (32GB vs 64).

Thanks!

The PNG files are just thumbnails of the last opened page (for display when browsing Notebook directory).

Notebooks do not take up that much space. They're stored as vector graphics.

[mergen3107]

@tomsem,

Thank you so much! That makes it easier

[jackm8]

Originally Posted by tomsem

It looks like some size reduction is necessary, either by reducing image dimensions or decreasing quality. Not surprisingly, ePub ends up about the same size as the CBZ I used (300MB+), and Send To Kindle has limit of 200MB.

Another option is to convert the KPF file directly to KFX or MOBI ('for old Kindles') directly for side loading.

Kindle Previewer 3 will Export to .mobi (mobi 7). It is considerably smaller but lacks any manga features: it just presents a series of images with manga page turns.

KFX Output plugin will convert KPF to KFX via CLI (it uses command line interface of KP3). There are some limitations to the KFX output (see plugin notes). I was able to convert the large KPF successfully with a 'might be too large for some devices' warning, but Scribe opened it just fine with full manga features.

Calibre conversion of ePub to KF8 succeeds (still 340 MB), the viewer does a reasonable job with it, but Scribe would not open it. Not too surprising. A 'suitably small' KF8 should load okay with full manga features as well.

As I understand it, KFX can be loaded into memory in segments, whereas KF8 has to load all at once.

I have been looking for alternatives to KCC. It does a lot of things I don't want it to do, and doesn't do some others I'd like it to do. I looked at forking the code but it was a mess back then (a year or so ago), and while I had some success in hacking in my feature, I was not happy with the result in the end. Kindle Create does most of what I wanted it to do.

The only problem is Kindle Create has no command line interface, so it is not very amenable to scripting.

I was fooling around with this the other day as well. Just testing stuff to figure what looks best. The way that looks the best later on Kindle was creating pdf, and sending it to kindle via 'send to kindle'.
Resulting .kfx and original .pdf are identical quality wise, but there's massive difference in how Kindle handles them.
PDF's gets white margin round the files, and progress bar percentage in the bottom right corner. If images are lower resolution than Kindle's screen, they don't scale up, and show smaller on the screen. If they're larger resolution, they get scaled down into white margins, EVEN images made in the precise 1860x2480px, get scaled down into white margins.
KFX rendering is much better. No margins. Whole screen is used. Smaller resolution images get scaled up. Larger scaled down.
No screensaver, no thumbnails in either case.

I did not use Acrobat, since it compresses images, and always transcodes png into jpeg. I simply used 'PDF24 Toolbox' - 'Convert images to PDF'—use dpi+dpi300.

What I'm trying to do now is skip all 'send to kindle' part. Converting pdf to kfx in Calibre via jhowell's kfx out plugin ended with similar results as sideloaded pdf. Cover on lock up screen, but even bigger white margins around images. End file also isn't considered as pdf by Kindle, I got font and spacing options instead of contrast options. Judging by log report, it converts pdf into epub, then coverts that into kfx. All those extra steps are good for epub to kfx, but mess things up in this case.

Originally Posted by sgt123456

I have a question about the resolution of sideloaded PDF’s on scribe. When a PDF is so large that you can’t simply send it to kindle with the send-to-kindle feature, I sideload it just plugin a cable and copying it to the scribe filesystem.

Doing this makes opening PDFs at scribe readable with the PDF legacy support that the device has. So it makes little margins (really thin ones) on the document when opened. I don’t mind having those little white margins, but I think the renderer is downscaling the images/pages and it makes little artifacts on words and images. So i was wondering if is there any way to figure out what the resolution of this “window” can be, just to get the PDF rendered like pixel perfect.

For the solution of too large files, you can just split pdf files into smaller files, and upload them separately. This will retain best possible quality. And is probably easiest way.
I don't know if figuring resolution of that crop on pdf files would get you anywhere, since you may case artefacts yourself by resizing images to it. But you could figure it by trial and error. Scribe screen is 1860x2480px. 3:4 aspect ratio. Make an image file that has exactly 1860x2480px dimensions, then go and create several smaller ones by a few pixels. Photoshop "image size", Faststone (free) "resize/resample" check preserve aspect ratio, and decrease resolution by 5px. About ten images should be enough. I'd write resolution of individual into a corner somewhere so it'd be easier to determine it later. Create a pdf out of those images, and upload it to your device, then just scroll through them. Fine tune resolution with 1px difference if needed. You can even test quality of rendering that way.