Saturday, November 2, 2019

Manuskript, Revisited

Back in 2017, I tried what was, at that time, a very young, very raw text editing program called Manuskript. It wasn't that useful to me for a variety of reasons. Fast forward to this year, and version 0.10 of Manuskript, and that's all changed.

My single biggest problem with Manuskript was that its editor is a markdown editor. At the time, I hated markdown. For me, it represented a huge step backwards -  embedding textual cues instead of WYSIWIG. I'd //used// editors like that, man, back in the bad old days, and I was happy to get away from them.

That was before I got into typesetting. A long time ago now, when my first novel, Looking Glass, was published, the original typesetter managed to lose all the italics.  If you've read that novel, that's a ton, and every one of them was missing. I never understood how that could happen until I tried it myself.

See, here's the problem.  No two WYSIWIG formats are the same. Even Microsoft can't get it right between versions of Word, and even RTF, the de-facto standard for slightly word processed text (and what I was using at the time) changes from implementation to implementation. The translators are never perfect. Having written one to go from Wordstar 3 to rtf, I understand why.

The short version is that styles are a problem. In an rtf, they're stored at the beginning of the file. If you switch between them in an orderly fashion, never using any of those nice formatting buttons at the top of your screen, all is well and good, although the file is still an atrocious mess inside. If you make any change //at all// to a style, you create a new style. Also, styles have real problems when you apply them to one word. They're really designed to style at the paragraph level.  It gets ugly, fast.

All this is hidden from the user, who can't (normally) see inside the actual file they're creating. It //looks// fine. If one of those styles gets sent over to typesetting software that's missing a font, or doesn't have the exact features of the version of rtf the word processing software did, things get messy, quick.  And the typesetter has to clean that mess up by hand.  Also, it's hard to search through and find, for example, "everywhere I used italics" because that may be part of three different styles plus in-line changes, and they probably use different codes to indicate these different methods. Worse, the translators have to figure out how to do something the target format may not really understand, which dumps a lot of machine generated formatting into the typesetting software that's usually, to put it bluntly, wrong.

Which brings us back to markdown.  Markdown avoids all this. Basically, it gives you a convenient shorthand for HTML, and the shorthand is designed to be human readable and publishable as it is. I'm not yet fluent in it. By the time I'm done with City of Glass, or whatever Brass and Steel II is called by the time it's done, I will be.

Manuskript's editor is still a markdown editor, but it also gives you WYSIWIG for the markdown you've added (at least, for the simple stuff I've experimented with so far.) Manuskript is much more stable than it was two years ago, and it has working spell checkers (thank your stars... my spelling is dreadful)  It's got what looks like a timeline feature I've yet to use. And. Most importantly. It plays nice with Dropbox.  I've lost data because the Scrivener format is really a directory of files with an XML header trying to keep them in sync. If you try to roll one back, you'd //better// make sure you roll back the xml, or you're in trouble. Manuskript does the same thing, really, and the version control (!) system that's built in is apparently not quite ready for prime time (so I haven't used it,) so as an option, it zips the file. Simple as that. One file, Dropbox saves the different versions, and if you want inside to look at your raw files, it's all there, in reasonably named folders (once you unzip the file) in plain text markdown files.

I don't really know if I like markdown yet. It may get inordinately tedious by the time I'm done with CoG. I may be screaming for stylesheets or //something// by the time I'm done. Or it may be that, in light of the fact that I'm typesetting my own work in separate programs now, that having a word processor with a built in semi-capable typesetter is not the best choice anymore. I don't know. Being able to see what I'm doing is handy, so I know I'm not making gross formatting errors in my markdown newbie phase. If this doesn't work for me... well... I did always want to write my own word processor... but even if I do, it'll probably output markdown and I'll bolt it up to Manuskript somehow. We'll see how it goes.


Thursday, July 11, 2019

Notes on the Raspberry Pi 4b

I recently got a Raspberry Pi 4/4GiB.  Below and in the comments are my notes from poking at it.

SSDs are now worth it. My ancient Apple laptop HDD got about 33MB/Sec for both buffered and direct access. My inexpensive (Inland) SSD got about 108MB/sec direct, and 198 MB/sec buffered.
On my big desktop Linux machine with the same $5(US) USB3-SATA interface, I got virtually the same numbers from the Ancient Apple HDD, a bit over 200MB/Sec buffered and  about 200MB/Sec unbuffered on the SSD.

The Pi's USB 3 interface isn't as fast as the one on my big Linux box. I know this. It's been publicly stated. It's still plenty fast. As I do not have a 7200 RPM notebook drive to test with, I'll just say that based on the specs, you //might// touch somewhere close to these numbers with a high performance HDD on a Pi, and if the budget is pinching, or you happen to have a 7200RPM notebook drive lying about, you won't do badly with it, but my experience has been that you will feel the difference with the SSD. Particularly with the Pi, where swapping is a way of life, I recommend the SSD.

Numbers generated using hdparm -t /dev/sda and hdparm -t --direct /dev/sda.

Saturday, January 5, 2019

Windows 10 from Virtual to Real

In preparation for moving my stepfather's windows 10 installation to an SSD, I was trying out clonezilla. Having booted my virtualbox windows 10 machine to the clonezilla iso, I duped the virtual system drive out to a spare SSD (ye gods. Spare SSDs). Figuring out how to test it was a puzzle, so I tried what seemed like a dumb idea. I took the duplicate of the virtual drive downstairs to the Intel NUC I use down there as a shop computer. It runs Linux normally, but with some bios kicking so it would boot from USB drives, it started reading the drive.

And guess what. It booted into Windows 10, with all of my apps in place, no problems.  I didn't know it would do that. I had to update some drivers, and I did //not// check to see if it was authorized, and I did //not// plug the SSD into the NUC's one and only SATA port (USB3 was fine) but taking the ship out of the bottle and putting it in the ocean actually worked.

Cloning a Linux machine wouldn't have surprised me. They don't have stupid DRM baked in. The fact that playing that fast and loose with a Windows 10 license did work was the surprise.

Learn something new every day.

Note Bene: My basement machine would be pretty much useless with Windows on it, so once I did a long-overdue BIOS update on the NUC, I shut down, unplugged the windows drive, and everything went back to normal. After some more BIOS kicking so it would boot from the built-in drive again. Bleah. I don't like UEFI bios much. Intel's version, even less so.


Blog Archive