Hacker News Reader

> Printing support is a super simple feature

Ah, the tell of someone who has never implemented printing.

Pagination across different paper sizes when content is dynamic/interactive and includes things like section headers that you need keep with text and images and tables that users expect to not split across pages with their custom choices of margins, page-numbers, page titles etc. So many other issues like ensuring monochrome prints are legible, implementing print previews etc.

Oh boy. Some might think implementing math from papers is hard but no, it's this sort of thing. You'll be fixing problems with it for the life-time of the product.

Of course, but in the case of Wave wouldn't it be sufficient to render the content as static HTML and let the browser worry about the rest?

Sure, that would make for a decent PoC. It's all the work that will come later as you discover the browser is NOT doing a good job that will be the problem.

If a browser fails to render HTML it's fair to say that's its makers' responsibility.

It may be different now, but it was not long ago that browsers would without remorse just let the printed page cut even images in half if a page break happened to be there. It seemed as if all they did was create an image of a length long enough to fit the printable content and just fed that to the printer. No smart layout at all.

If things are different now, it certainly was not during the brief time Wave was around.

Browsers don't normally work with paper-like pages, they work with essentially infinitely scrollable areas. So a browser layout engine is not in any way, shape or form optimized for laying out HTML + CSS in a printer friendly way, especially if you start having 'weird' requirements like A4 vs Letter, smart layout of tables across pages so that they are still readable etc.

In fact, in general, a human being must actually lay these things out by hand for print if that is the desired medium.

That doesn't matter. Layout is the job of the browser. If it sucks, it sucks. That is no reason for ugly hacks.

Which is an excellent attitude for a short PoC, but unimaginable for a paid product.

In the end, the user doesn't care. They want the printed page to be usable. If the browser makes it usable, excellent! If it doesn't, than the product is bad and an alternative must be found.

Sure, Google, being in control of Chrome, could implement a browser-level page layout engine.

Unfortunately, there is obviously no way to make a good general purpose layout engine, so that will never fly. Any site that wants to offer printing as a paid feautre must implement their own printable version, no question.

What was so special about Wave that a general purpose layout engine wouldn't be adequate?

Is that the realm of the driver?

It seems like the driver should detect paper size, broadcast a compatible print area/capabilities to something above, and then stand by to make any dot it can in the allowed area.

Why would the hardware driver need to deal with pagination, layout, or print previews (beyond advertising capabilities accurately)?

I've always imagined that drivers are hard on the hardware side. It is really difficult to reliably place dots on a page with the requisite precision/reliability at the price-point to which we have all become accustomed.

Strong disagree. Software quality is driven almost entirely by either insane dedication from hobbyists or (more commonly) monetary incentives. Lots of businesses depend on Postgres so it's good. Github makes money off of providing a good product. Wacom has a total stranglehold on the market so they don't care because they know artists will put up with it.

Wacom is seeing a lot of their lunch get eaten by iPad Pros now, so hopefully they’ll be pressured to improve. I wish Apple could make Sidecar integration work at Wacom levels so I’d never have to use one of their devices again though.

I don't know enough about the APIs involved but - that seems like something you should be able to write as a pair of apps.

You'd need a native iPad app to capture and transmit pen events, and then something on the desktop side to receive the events and turn them into the equivalent wacom tablet events. How does wacom send tablet events to apps? Is it a named socket or something? It shouldn't be too hard to emulate. I wonder if anyone's made something like that in the app store.

Mind you, I'd much rather if Apple baked it into macos through Sidecar.

Wacom uses kernel extensions, which is another reason why I’d rather it be a first party solution. Not sure what Astropad uses because their service requires an overpriced subscription, has a bad UI, and only functions well with an extra peripheral.

But Sidecar is also pretty half-baked and Apple is flakey about supporting features like in general, so who knows how it will all pan out.

There is indeed an app, Duet Display Pro, that will relay Apple Pencil input to your Mac. I've only used it for its second screen functionality; no idea how well the pencil part works.

Amazon offices use absurd amounts of paper.... however it's mainly for raising desks and leveling monitors. Literally every desk has some thing up on a ream of paper. The actual paper document culture is moving online finally.

Ah, Google has solved half this problem by providing powered sit and stand desks. But people still use reams of paper to hold up their monitors.

Most people also position their monitor too high, to be fair. The top of the monitor should be at or slightly below eye level. If you reach out from your chair with your arm held level, that should be roughly in line with the middle of the screen, and your fintips should be ~10cm or a few inches away from the screen.

This seems wrong to me.

I very purposefully position my monitor so that my main console window is viewed, with my head level. It is also horizontally centred on the mid-left of that console.

This is because most text, eg bash work, vi of files or code, rests there.

In this way, my head is not tilted down, or eyes tilted down constantly. My head is mostly centred, and looking straight ahead.

I find that elsewise, my body follows the constant downward look, either slouching or the neck bent forwards.

Why do you belief your monitor should be positioned, so you are looking downward constantly?

The point isn’t that you should be looking downward, it is that you shouldn’t be looking upward. It creates eye and neck strain.

For me, constantly looking downward causes neck strain.

Hence the top of the monitor being at eye level, is problematic. I think the best scenario is most-often level.

I wonder, I grew up before laptops and smartphones. These often result is down-gazing a lot. Hmm.

Multiple ergonomics guides give the guidance I mentioned. Here’s a link to a few, but I encourage you to do your own research.

At the end of the day, if you’re finding that something helps to reduce long-term fatigue then it’s probably not too bad, but don’t forget that slouching in your chair feels good however it’s terrible ergonomically - this is similar. Comfortable short term, but not always long term.

All of these recommend at or slightly below eye level:

https://www.ors.od.nih.gov/sr/dohs/Documents/Computer%20Work...

https://www.osha.gov/SLTC/etools/computerworkstations/compon...

https://www.ccohs.ca/oshanswers/ergonomics/office/monitor_po...

https://www.worksafe.qld.gov.au/__data/assets/pdf_file/0006/...

https://www.mayoclinic.org/healthy-lifestyle/adult-health/in...

Etc..

The search I ran in google was “monitor ergonomics gov”

Of course though, because the monitor and keyboard should be able to be raised and lowered independently. If you set the desk to a height that's suitable for the monitor, it may be too high for the keyboard.

I have a adjustable keyboard tray.

Amazon has powered desks in new buildings as well. It doesn't solve the monitor positioning problem esp with multi-monitors and evening things out.

> I have a working theory that any software used by programmers will eventually get excellent

Most programmers rarely using office suites and prefer to use plain text editors. This has gone so far that developers prefer a sadistically under-featured file-format (.md) to office files.

What you call underfeatured many would call correctly featured. A more complex format doesn't add value for most use cases, while being harder to reason with and correct issues in.

.md files avoid the copy paste font/size mess by being plain text and rendering in the reader's choice of font. Bold, italics, hyperlinks and such are all explicitly added, easy to Ctrl + F for and aren't hidden behind finicky context menus as in standard word processors.

Plain text formats do have advantages but Markdown is a pretty bad one.

Personally, I prefer a lightweight, portable, easier to edit, technically just plain text file vs whatever mess of useless fonts/font sizes/unrelated garbage is crammed into a .odf/.docx file.

Literally anyone with a computer that has a ASCII or Unicode compatible text editor can open a .md file and get useful info.

Even better, add a little bit of lightweight extra tooling, and now you've generated a nice looking html page, if you need to make something with fancier presentation.

The only thing I miss is the ability to embed images in the md file itself, but even that is not hard to work around.

Obviously I keep software on hand that can deal with docx/odf, but I'd really rather just keep it simple, due to the fact that I'm stupid.

> This has gone so far that developers prefer a sadistically under-featured file-format (.md) to office files.

And doesn't have a proper spec. The best we have is https://commonmark.org

I would say at least GFM's spec is reasonably detailed, given how much GitHub depends on it.

https://github.github.com/gfm/

> I have a working theory that any software used by programmers will eventually get excellent (or be replaced with something excellent). And everything else stays vaguely mediocre.

Hmmm... I think.. sometimes. There's also software that gets excellent, becomes big, becomes profitable, and squeezes out everything else. Then becomes mediocre. word and google docs?

I would be unsurprised if a lot of drivers remain closed source to hide where the bodies are buried. There's probably a lot of dodgy hardware that's somewhat papered over with fixes in a 200Mb propriatery drivers-- much easier to filter the inbound data and build a workaround than ship everyone a new controller board when it turns out sending 0x08675309 grenades the print head.

SharePoint is actually reasonably effective.

It's certainly not non-existent.

(There's now browser based versions of MS Office apps that can simultaneously edit documents stored and automatically version controlled in SharePoint)

Version control for word documents is horrible though. To review each change it opens up a new word instance.

I dealt with SharePoint less than 5 years ago.

In some ways it was truly awful, to mention two examples:

- a reason for using it was to automatically apply Azure Information Protection to documents. All well and good until it turns out the mechanism can trivially be subverted, so trivially that we found out by accident by not following the exact login procedure.

- the usability makes is comparable to Oracle software. I have extensive experience with that too, but I can't say which is worse.

How do we get programmers to use bank teller software?

Oh, y'all gotta pay for that.

Alternatively, how do we teach bank tellers to program?

By teaching the current school aged kid's to program.

I seriously think the world would be better off if programming were seriously taught in schools, on a level equivalent to language, math, science, etc.

If we start with Scratch in early grade school and work up to C in high school, so many more people would be comfortable and efficient using computers, and would have the understanding necessary to understand the legislation of tech.

This would take a decade+ to pay off/have the bank tellers know to program, but it seems like the best long term plan.

I agree. Programming shouldn't be (just) thought of as engineering, but also as simply giving the computer complex instructions. There is also the story about RMS teaching secretaries to program Emacs by not telling them Lisp is a programming language.

> Programming shouldn't be (just) thought of as engineering, but also as simply giving the computer complex instructions.

I really like this phrasing. I'm not really an engineer. My code is mostly rough, but it is functional and does what I need it to. I don't program to build a skyscraper, I program so my computer can do a thing I need it to do.