[GUI Plugin] Modify ePub

[icallaci]

Just confirming that Modify ePub v. 1.5.9 works great on my Win 10 64-bit setup running Calibre 4.23. The previous (beta) versions all exited with errors.

[ilovejedd]

Originally Posted by hobnail

My recollection was that Macs used CRLF (and Windows used LFCR as chaley points out). I remember opening Mac files on my Unix system and having CRs at the end of each line (and Windows files had a CR at the beginning of each line). If it was only CR then it would be one long line with no line breaks.

Iirc, Windows is CRLF. Mac is either LFCR or just CR.

[binaryhermit]

Rant, it'd be nice if software spoke all 3, I still run into issues where Linux doesn't understand non-native encodings, often involving md5 checksum files, and I need to invoke dos2unix.

[chaley]

Originally Posted by Rev. Bob

As to the rest: It’s a very minor thing, one which as far as I can tell is completely cosmetic, so I have no problem leaving it as is. I simply found it and thought, “he might want to know about that.”

Originally Posted by JSWolf

I just tested 1.5.9 with 5.0.1 and no errors and no funny characters in the editor. Everything seems good with both 5.0.1 and 4.23 with version 1.5.9. Unless anyone else finds something wrong, I think we are good to go.

Originally Posted by icallaci

Just confirming that Modify ePub v. 1.5.9 works great on my Win 10 64-bit setup running Calibre 4.23. The previous (beta) versions all exited with errors.

Good news. Proposal: if there aren't any (significant) problems overnight (my time, it is nearly midnight here) then I will release it in my AM. At that point excrement may hit rotating blades. I hope not. If you object, speak now or forever hold your peace.

[chaley]

Originally Posted by binaryhermit

Rant, it'd be nice if software spoke all 3, I still run into issues where Linux doesn't understand non-native encodings, often involving md5 checksum files, and I need to invoke dos2unix.

I agree. Unfortunately this is very hard, often involving "magic". I just spent nearly 3 days working on this plugin trying to deal with this "magic", in the end failing.

[BetterRed]

Originally Posted by binaryhermit

Rant, it'd be nice if software spoke all 3, I still run into issues where Linux doesn't understand non-native encodings, often involving md5 checksum files, and I need to invoke dos2unix.

Be even better if all OSs used the same one, can't remember what RT11 used but seeing as everything since has borrowed from it, they should have stuck to what it used - cue Univac, Burroughs, GE, Marconi… etc aficionados

BR

[DNSB]

Originally Posted by chaley

Good news. Proposal: if there aren't any (significant) problems overnight (my time, it is nearly midnight here) then I will release it in my AM. At that point excrement may hit rotating blades. I hope not. If you object, speak now or forever hold your peace.

Just a bit of text to keep MobileRead happy that I am actually replying.

[JSWolf]

Originally Posted by DNSB

Just a bit of text to keep MobileRead happy that I am actually replying.

It's not the engineers you shoot. It's the managers.

[DNSB]

Originally Posted by JSWolf

It's not the engineers you shoot. It's the managers.

Not quite right. You shoot the managers to keep them from shipping gamma code just to get it out the door. You shoot the engineers when they don't want to ship the code until every line has been polished to perfection.

"Perfection is the enemy of success." Mark Cuban

[Terisa de morgan]

I totally, totally agree with David. In some cases, we engineers don't take into account that the best is the enemy of the good.

[JSWolf]

The managers who want the engineers to do some really outrageous things should be shot first.

[chaley]

The behavior difference that @Rev. Bob pointed out is almost certainly benign. but it does bother me a bit. And it turns out not to be necessary. I decided to use the python version to condition the magic of how EOL is treated. The attached version preserves EOLs.

It should be noted that the plugin explicitly changes CRLF to LF in a ton of places depending on options. Because of this, one cannot depend on preserving CRLF. They are preserved if only "Update Metadata" is checked, so basic file IO works.

The change has no impact on the plugin running on 4.23.

I am tempted to release this version but that would be tempting fate. I will do so later today (around 9 AM GMT) unless 'bad things happen'.

[chaley]

Originally Posted by DNSB

Just a bit of text to keep MobileRead happy that I am actually replying.

Were you "speaking now" or "holding your peace"?

Thanks to all who took time to test, over and over. We never would have arrived here without you.

[JSWolf]

Originally Posted by chaley

The behavior difference that @Rev. Bob pointed out is almost certainly benign. but it does bother me a bit. And it turns out not to be necessary. I decided to use the python version to condition the magic of how EOL is treated. The attached version preserves EOLs.

It should be noted that the plugin explicitly changes CRLF to LF in a ton of places depending on options. Because of this, one cannot depend on preserving CRLF. They are preserved if only "Update Metadata" is checked, so basic file IO works.

The change has no impact on the plugin running on 4.23.

I am tempted to release this version but that would be tempting fate. I will do so later today (around 9 AM GMT) unless 'bad things happen'.

Don't you mean 9pm GMT as you've already posted this past 9am GMT.

[chaley]

Originally Posted by JSWolf

Don't you mean 9pm GMT as you've already posted this past 9am GMT.

Yes