Hacker News new | past | comments | ask | show | jobs | submit | lidavidm's comments login

Only because Western-centric systems don't handle non-LTR text properly.

https://atadistance.net/2019/10/20/japanese-text-layout-for-...

> Baseline font metrics will never deliver great CJK typography because there are too many limitations. > > This is why InDesign J implements virtual body metrics based on Adobe proprietary table information for true high-end Japanese layout. There is no virtual body standard digital font metric standard so everybody implements the missing stuff on the fly and everybody does it different. Unfortunately the irony of it all is that Adobe played a huge role in how these limitations played out in the evolution of digital fonts, desktop publishing (DTP) and the situation we have today.

I have a Kobo reader which supports both ePub 2 and ePub 3, and IIRC you need ePub 3 in order to get proper RTL/top-to-bottom text and Japanese typesetting, as well as proper comics support (if you buy an ePub 3 manga, it'll properly flip the page turn direction and the progress bar; a CBZ or other format won't). But most other readers I run into don't understand ePub 3 properly.


Could consider a Kobo Elipsa. (I have a different Kobo device.) It runs some sort of Linux and you can install Koreader and a couple of other things. You can tweak a config file and set up the device without an account. Not sure how the writing experience compares to reMarkable, though (probably not favorably).


I posted some other comments in this thread - unless they've significantly improved the software in the past year I would 100% recommend against it.

(Also, a lot of manga gets distributed through proprietary apps now so an iPad is probably your best bet anyways, at least if you read the serialized version and not the tankoubon releases...)


The eReader functionality is... poor but usable.

EPUB rendering is slow the first time you open it, and notes and highlights get lost when you change text size.

On the other hand, PDF rendering is excellent. I make it a point to buy PDF versions of ebooks and have had no issues using it like that.


Kobo lets you tap and hold a corner (or hold down the page turn button), and after a second it'll start fast-flipping through pages. Not as fast as an iPad but pretty quick, sorta like flipping through a book at a moderate pace.


I had a reMarkable 2 and gave up it almost solely because it didn't support USB mass storage (like Kobo devices do), making it really annoying to transfer files. Also, their software update made the reader worse, since I went from being able to manually crop the page to fit the viewport to having to carefully pinch-zoom with a bunch of latency and really weird sensitivity. And they seem oddly insistent they're not a reading device anyways; if they supported ePub 3 (particularly ePub 3 fixed layout - again, Kobo supports this) that would have made it a nice comics machine, but no. (And their weird web interface choked if you tried to transfer "large" books.)

100K JPY too, which is in the range of an iPad Air. I hope some of these software issues get ironed out and maybe I'll consider it again...


> Remarkable 2 and gave up it almost solely because it didn't support USB mass storage, making it really annoying to transfer files

We had hoped to buy these for all our paperless office employees, and gave it up almost solely because it was far too easy to transfer files.

If they deliver a device with on-device encryption (as this claims) and sync or manual transfer tied (and locked) to company-owned storage, we'd buy them for all our Pro(fessionals).

To your point, instead we give our professionals iPad Air with Paperlike™ for pencil-feel and a keyboard for on-the-go use. We'd rather (for reasons) give them Remarkable Pros if it was capable of meeting Professional data-loss-prevention (DLP) needs.


Let me ask you this in all seriousness and with minimal snark - do you confiscate employees paper notebooks when they leave the company?


We expect people to have a labbook per project. They are logged when handed out, and signed back in at the end of the project.

For a science/engineering firm, this sort of arrangement isn't uncommon, because stuff you do in the lab leads to customer deliverables.

Of course, people can also do things electronically, which they increasingly do.


There are jobs where producing a paper notebook is the primary deliverable. Fewer than there were, due to y'know, computers. But it still happens.

It's odd to describe that as confiscation. A lab notebook belongs to the lab, not the researcher, this is understood by both parties. They may or may not have permission to leave the lab with it, but making personal copies of the pages would be espionage.

It's perfectly reasonable to want comparable properties in a paper-replacing device. I can see where you might find that jarring if you haven't been exposed to work conditions where it's normal and expected.


I worked at company that required all paper notebooks to be handed in and destroyed. There are entire companies based on destroying sensitive paper documents.


They know that smartphone have cameras?


employees often aren't allowed to have them onsite in these circumstances for this precise reason.


I hope you don't mind this bit of feedback - your comment comes off as snarky, which may not be what you intended.

People are talking about their experience in sensitive areas, and so restrictions on devices you can bring in/out is fairly typical.


If you can transfer gigabytes of data with a paper notebook then I’m really impressed! But seriously this is similar to banning usb flash drives and the like, it’s not that unusual.


I used to work at a federal contractor. Any paper you bring to the building /never/ leaves again. I liked to keep notes in a legal pad and would just shred them.


This isn't unreasonable or unheard of in some contexts, especially anywhere requiring a security clearance.


As you see in sibling replies, in many industries where a given hand writable concept has intellectual property value readily assessed in the millions to billions, and/or the deliverable itself may be in written or sketch form, it's quite often true that:

(a) employees aren't allowed to have/use their own paper notebooks in the first place

(b) if they do, then, yes, the notebooks don't leave unless Security reviews (if removal is even allowed)

However, any number of such traditional approaches stop working when remote work is a thing.

Technologies are needed if a firm wishes to retain the same level of awareness of what's happening to its IP while allowing employee flexibility (which, hopefully, firms are learning they should strive to allow).


They also stop working if employees are allowed to bring their phones into the building.


Not the OP, but eInk tablets are banned at our work for the same reason, and paper notebooks don't get destroyed.

I one of the reasons is it's easier for a malignant actor to get access to notes without you knowing when it's electronic. At least with a paper notebook you can tell if it's missing.


Similar experiences with the reMarkable 1. The USB interface really bugs me. It's nice for annotating and highlighting PDFs, but pretty bad for reading. Great for taking notes, but awful at extracting them, unless you get an expensive subscription to their "cloud" garbage, which feels extortionate considering how expensive the device is.


You can ssh into the remarkable and copy files via scp.


But, afaik, they keep an index and some extra files in their own format to track them [0], so you can't "just" upload the files. You need a tool to do that additional work.

I use RCU [1] for that.

  0: https://remarkable.jms1.info/info/filesystem.html
  1: https://www.davisr.me/projects/rcu/


Yeah. Still way more effort than Kobo: plug it in, drag and drop.


I've switched to exclusively using SSH on my Kobo, because I find it less effortful. The connection procedure consists of enabling wifi on the Kobo and clicking on the sftp bookmark in my file browser.


Wait is this an official method?


No, it's KFmon stuff.


What's wrong with the USB web interface of the remarkable, though? It is quite spartan, but I haven't updated mine in ages, so I imagine they have improved it.

The workflow is plug -> web browser -> remarkable IP -> drag and drop.


What does the customer gain from having a web interface you have to navigate to by IP rather than a simple external storage device that shows up like a flash drive?


I think one reason for the web interface is that the device stays usable. If it would export a block device then it would need to unmount the file system on itself or at least block changes. If I remember correctly in the old days before MTP, all Android did this, making storage on the device itself unavailable while making it available via USB.


Yeah, that would be an issue with presenting the device as a block storage device.

The web interface also has a couple of other advantages: the tablet simultaneously listens for ssh connections, and can be used over Wi-Fi, IIRC? Though it could also expose a "USB HUB" with both the network interface and block storage.

I just wish we had a more ubiquitous "network file storage" protocol. The tablet itself could offer NFS, but mounting it under different operating systems would be a pain, requiring manual user intervention.


That's still quite a bit more than just plug -> drag and drop, also especially because sometimes I had to manually bring up the interface, and remember some IP that I might only use every week or two at most. (I guess I could set up a bookmark, sure.) Also, it chokes on large-ish files (it would just never upload, no indication in the UI), so I had to split up books.

Anyways, I think I could have dealt with it if it handled large books fine.


I'd guess most people here don't actually take buses on a regular basis. (Or ever. Or any public transit at all.)


Oh boy. Hope you never run into a CalorieMate or a jelly squeeze packet. Or the stoveless apartments.


Those are intended for quick meal replacements, not replacements for eating entirely.

And stove less apartments are usually for people that eat out, not people that are trying to replace meals with shakes.


GCC can also use UBSan (and ASan) [1], and furthermore, it shouldn't be "several times slower" (are you thinking of Valgrind?). Clang itself describes the checks as "small runtime cost" [2] and there's a minimal variant as well.

[1]: https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.h... [2]: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html


You can't without de-DRMing. That's basically the point, right? Amazon has locked you in to their ecosystem.


Kobo works quite well: you can set it up without an account (needs a bit of manual fiddling) if you really want, and either way after that you can just plug it in and drag-and-drop epubs to the device. Battery life, responsiveness, etc. are all fine to me (the older devices actually did a bit better IMO and it mostly only gets bogged down for comics, regular books are fine)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: