This is marked as pre-alpha because of the Unicode backend changes… it is stable for me, but I don’t do a lot of Unicode work. RTF and DOCX File IO isn’t unicode aware yet either.
This is a bug fix only release, and all users are recommended to update.
Fixed Tickets #37 RTF files not saving Fixed Tickets #36 Catch Window close to possibly save file Fixed Tickets #35 DOCX incorrectly says it can save files Fixed Tickets #34 Wordstar save fonts failing Fixed Tickets #32 Crash on macOS when exiting Fixed Tickets #30 page break spacing while editing
Note on Wordstar fonts
Switching from WxWidgets to QT lost us some granularity on fonts. With WxWdigets, I was able to find out is a font was serif or san serif, proportional or monospaced, and even what codepage it was from. I haven’t figiured out how (or if) I can do that in Qt yet. Any Wordstar file loaded with font information will saved with that font information intact. If you insert new fonts during editing and save, those new fonts will be converted to Courier or Times New Roman, since the only information Qt gives me is proportional or monospaced. Ugh.
What happened to 03..312?
I released it with RTF file saving turned off, so I deleted the release and did a quick update to 0.3.313 with that error fixed.
This is another large release. This is the first stable release with a complete UTF-8 based backend. I’m still calling it pre-alpha because I’ve only really run it on Linux (quite extensively).
In this Release:
UTF-8 Backend (see below for tech details)
New RTF loader (less complete, but more robust)
New DOCX loader (incomplete, but not bad)
Yeah, a lot of corner-cases from moving to UTF-8
Actual UTF-8 data entry from keyboard has not been tested, just copy from web to WordTsar.
I reset the build number for this release. Don’t ask me why, I can’t remember.
Every version of WordTsar has been using a gapbuffer for it’s underlying document buffer. Adding UTF-8 support added created issues with the single buffer issue. We now use a plain buffer per paragraph, and have seen some slow downs because of it. We’ve added caching that should get around that.
Carat movement is all grapheme based. If a grapheme is made up of multiple codepoints, deleting will remove the entire grapheme.
The File save and load routines don’t fully understand UTF-8 yet. Wordstar file save and load most likely never will.
I’m a Canadian English writer. All of this UTF-8 stuff needs more testing than I was able to give it.
I’ve been developing various pieces of software in wxWidgets (back when it was called wxWindows!) for a long time. But recently, I’ve made the switch to Qt.
WordTsar under wxWidgets was stable, and I used it to write quite a few novels (http://geraldbrandt.com), so why the switch? Well, it seems that I always had to do something just a little different based on what platform the software was running on. Don’t get me wrong, 99.9% of the code was cross platform and worked well, but there always seemed to be corner cases.
The last straw for me was when I tried to get WordTsar running under MacOS. I tweaked here and there. Keyboard input was a pain, but then it was under Qt as well. It was just easier under Qt because I’d already fixed the issue under wxWidgets. So, what was it that I couldn’t get working?
I use timers to update WordTsar’s status bar, do word counting, and flash the carat. None of it worked under MacOS. Again, I tweaked here and tweaked there, but I just couldn’t get timers to work. Really, timers are a pretty basic function. They should Just Work.
About two years back, I did a test port to Qt to help me find an elusive bug. I moved over just enough code to help track down the bug, and stopped. This time around, I didn’t.
WordTsar is now 100% Qt based, with all the functionality of version 0.1 Release 1977. Well, almost. The Linux version of WordTsar had spell check working, using Hunspell. Non of the other ports did. I’ve decided to leave spell check out since I want to do it in a more cross-platform way.
What differences will you see with the Qt port? Some of the dialogs look different. Yup, that’s pretty much it.
Well, except for one thing.
The Qt version is SIGNIFICANTLY faster than the wxWidgets version. Why? Two things in particular:
Measuring of text under Qt just flies. Under Linux, measuring the widths of 605,814 characters took roughly 1800 ms. With the code optimized to measure strings instead of characters, I got that down to 460 ms. Under Qt, which can only measure individual character widths* the speed is 138 ms. That is a massive speed improvement.
QString vs wxString is the second big increase. I do a lot of parsing of strings using .Mid(), .BeforeFirst(), .Left(), etc. I do no in string indexing (i.e. string[x]). Parsing WordTsar dot commands (string heavy) on a 111,000 word novel took 1060 ms under wxWidgets. With Qt, that process took 348 ms. I was planning to optimize the dot command routines to speed things up, and I still will (via some form of caching), but I can postpone that work now.
What this all comes out to, is under wxWidgets, laying out a 111,000 word document took 1670 ms. Not bad, really. Under Qt, the same process takes 576 ms. That’s a very noticeable difference.
I’ll be testing the Qt version over the next week by editing a 92,000 word novel and bringing that up to 100,000 words or so. Not a bad stress test. If all works out, there will be a WordTsar 0.2 Release xxxx happening next week for Linux, Windows, and MacOS.
* wxWidgets has GetPartialTextExtents() which, when passed in a string, will return an array of character widths. Qt has no such function. You can get the width of an entire string, but not the characters in that string. So, with Qt, I must measure each character.