#Using wordstar for windows on windows 7 update
#Using wordstar for windows on windows 7 code

* wxWidgets has GetPartialTextExtents() which, when passed in a string, will return an array of character widths. If all works out, there will be a WordTsar 0.2 Release xxxx happening next week for Linux, Windows, and MacOS. 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. What this all comes out to, is under wxWidgets, laying out a 111,000 word document took 1670 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. Parsing WordTsar dot commands (string heavy) on a 111,000 word novel took 1060 ms under wxWidgets.

QString vs wxString is the second big increase.

Under Qt, which can only measure individual character widths* the speed is 138 ms.

#Using wordstar for windows on windows 7 code

With the code optimized to measure strings instead of characters, I got that down to 460 ms. Under Linux, measuring the widths of 605,814 characters took roughly 1800 ms. Measuring of text under Qt just flies.

The Qt version is SIGNIFICANTLY faster than the wxWidgets version. What differences will you see with the Qt port? Some of the dialogs look different. IРІР‚в„ўve decided to leave spell check out since I want to do it in a more cross-platform way.

The Linux version of WordTsar had spell check working, using Hunspell. WordTsar is now 100% Qt based, with all the functionality of version 0.1 Release 1977. All of this UTF-8 stuff needs more testing than I was able to give it. Wordstar file save and load most likely never will. The File save and load routines donРІР‚в„ўt fully understand UTF-8 yet. If a grapheme is made up of multiple codepoints, deleting will remove the entire grapheme. WeРІР‚в„ўve added caching that should get around that.Р”В¬arat movement is all grapheme based. We now use a plain buffer per paragraph, and have seen some slow downs because of it. Adding UTF-8 support added created issues with the single buffer issue. DonРІР‚в„ўt ask me why, I canРІР‚в„ўt remember.Р”В®very version of WordTsar has been using a gapbuffer for itРІР‚в„ўs underlying document buffer.

I reset the build number for this release.

Actual UTF-8 data entry from keyboard has not been tested, just copy from web to WordTsar.

Yeah, a lot of corner-cases from moving to UTF-8.New DOCX loader (incomplete, but not bad).New RTF loader (less complete, but more robust).UTF-8 Backend (see below for tech details).IРІР‚в„ўm still calling it pre-alpha because IРІР‚в„ўve only really run it on Linux (quite extensively). This is the first stable release with a complete UTF-8 based backend.

#Using wordstar for windows on windows 7 update

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. 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. I havenРІР‚в„ўt figiured out how (or if) I can do that in Qt yet.Р”Р„ny Wordstar file loaded with font information will saved with that font information intact. 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. Switching from WxWidgets to QT lost us some granularity on fonts. This is a bug fix only release, and all users are recommended to update.Р”Р‡ixed Tickets #36 Catch Window close to possibly save fileР”Р‡ixed Tickets #35 DOCX incorrectly says it can save filesР”Р‡ixed Tickets #34 Wordstar save fonts failingР”Р‡ixed Tickets #32 Crash on macOS when exitingР”Р‡ixed Tickets #30 page break spacing while editing RTF and DOCX File IO isnРІР‚в„ўt unicode aware yet either. 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.