Atlantis Word Processor 4.3 (beta)

[Eduardo]

Atlantis 4 beta4
Windows 10

While in Options and trying to access the menu for the Spell check, Atlantis crashes. I will be describing bellow the steps and error messages until the crash.
-Tools
-Options
-Spellcheck
-SpellCheckers & Dictionaries
-OK
(Messages after pressing OK):
- Debug exception
-TStringList.PutObject0:invalid index
-Debug call stack:
-TCommandManager.ExeCommand 0:
Command 640

(pressed OK)

-Put the command of the active document onto the clipboard?
(either way pressing OK or not, freezes Atlantis).

I reinstalled the Portuguese speller. I also have the Us and Canadian spellers installed. It didn't make any difference in regards to crushing.

I hope this helps.

Thanks for your efforts, by the way.

[admin]

Make new document, add a list, save reopen, edit say adding a new entry in the middle of the list

Cannot get an error on my system. The problem is that there are different ways to “add a list” and “add a new entry”. It would be good to have more precise instructions.

Could you please email your test document with a list to support@atlantiswordprocessor.com, and tell what to click and what to press after opening it? Please also email your Atlantis.ini file from “My documents\Atlantis”.

And please make sure that your beta copy is up-to-date (choose "Help | Check for Updates...").

[admin]

While in Options and trying to access the menu for the Spell check, Atlantis crashes.

Eduardo, please zip the “Spellcheck” folder from “My documents\Atlantis”, and email the zip file to support@atlantiswordprocessor.com. Please also email your Atlantis.ini file from “My documents\Atlantis”.

[fergch]

Thanks

Updated to Beta vb4
Doing the following steps...

Start a New Document Doc94.rtf
paste 42 lines of text (from a .txt file, so no formatting)
wait for a time...10 seconds...
This error appears on screen

2023_04_05_11_01_56_Atlantis_Word_Processor_Doc94.rtf_.jpg (113.76 KiB) Viewed 340016 times

Happens every time

Then this

2023_04_05_11_05_00_Atlantis_Word_Processor_Doc94.rtf_.jpg (121.67 KiB) Viewed 340016 times

Click yes (or No)

document frozen

close document (x in top right corner)
this message

2023_04_05_11_07_15_Atlantis_Word_Processor_Doc94.rtf_.jpg (139.18 KiB) Viewed 340016 times

Click No - program frozen - crash -

Restart Atlantis then the same routine can be repeated

Requested attachments will arrive soon.

My previous testing was with an existing document, Selling Stuff.rtf, and putting the cursor down a few lines, say at number 14, press enter (to add a new entry at number 15) and the first series of errors shown in the first message followed using the Beta, but not using ver 4.2.2.6

Thanks

[Alan]

I use a hard coded first line indent of one Em Space and one Four-Per-Em Space. I will often copy a word from a spell check list in another document and insert it at the beginning of the paragraph that starts a book's story to find all occurrences when updating formatting. I have noticed that when I do this the first of the 2 space characters is deleted. When finished reformatting the word throughout the document I go back and delete the word I had inserted, which deletes the second space also. After inserting a word that deletes the first space I have retyped it, made my changes, come back and deleted the word inserted only to have both spaces deleted also. I tried a third case typing in the 2 fixed width spaces to start a new paragraph and pasting in after them, this caused the 2 spaces to be deleted and only the pasted in text to remain in the paragraph. The deleting of the fixed width Unicode spaces has happened every time in the Betas.

Alan

[admin]

Requested attachments will arrive soon.

Thanks, Chris and Eduardo. This bug has been fixed. Please update.

[admin]

I use a hard coded first line indent of one Em Space and one Four-Per-Em Space.

I do not think that using spaces for indentation purposes is a good idea. You can use proper paragraph indents, or tab characters with custom tab stop positions.

Alternatively, you can uncheck the “Smart cut & paste” option on the “Edit” tab of the “Tools | Options...” dialog.

[fergch]

Thank you, update applied.

Another small problem is that writing time is now a bit hit and miss. A document that has writing time showing in the status bar is visible, but cycling through open .rtf documents results in the writing time disappearing, then it is gone for all documents, even the one that had the writing time present and displaying.

[Alan]

Hi admin,
The documents I am working on are both for printing and conversion to ePub so tabs will not work. I do not know how to convert from Em spaces to points, I now use points for measurement exclusively since starting to create documents for both printing and ePubs. Em spaces have the advantage of giving the correct (proportional) indent no matter what the font point size.

Alan

[rstroud]

Em spaces have the advantage of giving the correct (proportional) indent no matter what the font point size.

Alan, you are worrying about something that you do not need to worry about. I was going to address your concern, and I took some old material of mine from years ago and saved it as an .epub. In doing that, I discovered something about the drop caps that I want to bring to the attention of the Administrator. Maybe I will return, in a subsequent post, to your concern about proportional line indents.

I deliberately made a drop cap for this example, and I discovered that it is not working correctly in the .epub version. I do not remember whether it worked properly before the new beta versions, because I have not used the drop cap for an ebook in a long time (if ever).

Administrator, please try some text with a drop cap and save it as an .epub. When I did this, the drop cap was sunk too low, sort of like the previous problem with small caps (which you have already fixed).

I tinkered with the code in Sigil and corrected the problem, but my CSS was different from what Atlantis produced. Here is my result, with the corrective code.

Code:
.t1
{
float: left;
font-size: 300%;
line-height: 90%;
margin-right: 0.12em;
margin-bottom: -0.2em;
}



I have adjusted the code so that the result is very nice-looking. However, this is not the result that Atlantis produced with "Save As ... epub".

[Alan]

I have found another oddity in Spellcheck. In the current book in which I am updating the formatting I had put Reversed Double Prime and Double Prime characters around the story titles mentioned in the Introduction. One title is ‶Liar!″ with a red underline starting at the capital L and ending under the Double Prime. I did a test on a nearby phrase so marked and not red underlined and found most punctuation, though not the ellipsis, caused a red underline.

Alan

[rstroud]

I thought it might be helpful if I elaborated a bit on the "drop cap issue". It was the middle of the night when I posted about this above, and I did not want to take time to make graphics of everything. So, anyway, here is the complete story.

The drop cap works fine in the current beta for producing a document (I only tested with .rtf, but I assume that .docx works all right, too). Here is a paragraph with the drop cap set for two lines:



However, the .epub document that Atlantis produces pushes the drop cap downward too far:



And here is the associated code for the drop cap (the code that Atlantis generates):



Here is the code as I tweaked it. I left out the 'vertical-align' because I could not determine that it was doing anything, even if I made changes to it:



And here is the resulting .epub after I tweaked the code:



- - - - - - - - - -

I will take this opportunity, also, to say to Alan that the best way to handle first-line indent is with styles and to use something like a 0.25" for any kind of small format book or for an ebook. It is unnecessary to try to use an exact em (of a particular font size) for an indent. If you have instances where you need a bigger indent, just make another style with a bigger first-line indent. But trying to match indents with the em-size of a particular font size is just extra work for no good reason. I have been working with fonts and sizes and layouts all the way back to the 1970s, when we had to do paste-ups with light tables.

For practical work, we say that an inch has 72 points. An em has the number of points of the font size. When you are dealing with 12-point type, an em is 12 points, and an inch has 6 ems. An em-space of a very small font is smaller than the em-space than a 48-point font.

Do whatever you would like, but I see no reason to tinker with indents because the font size has changed (at least, it is unnecessary unless you have a very great change from one font size to another).

[admin]

Another small problem is that writing time is now a bit hit and miss. A document that has writing time showing in the status bar is visible, but cycling through open .rtf documents results in the writing time disappearing, then it is gone for all documents, even the one that had the writing time present and displaying.

The status bar sections have dynamic widths. Atlantis may make them wider to accommodate current stats for the active document. You might wish to disable some sections of the status bar to free more space for the sections you actually need - choose "Tools | Customize | Status Bar...".

[admin]

I have found another oddity in Spellcheck. In the current book in which I am updating the formatting I had put Reversed Double Prime and Double Prime characters around the story titles mentioned in the Introduction. One title is ‶Liar!″ with a red underline starting at the capital L and ending under the Double Prime. I did a test on a nearby phrase so marked and not red underlined and found most punctuation, though not the ellipsis, caused a red underline.

Now these two symbols are treated correctly.

[admin]

However, the .epub document that Atlantis produces pushes the drop cap downward too far:

The drop caps in Atlantis (and MS Word) are normally formatted with vertical offset (lower location) and a fixed line height. These characteristics are computed based on the text height and line spacing of the "normal" text of the paragraph, the outline metrics of the drop cap character, and the drop cap format. You cannot replicate all this in HTML/EPUB using some algorithm. You can, of course, tweak your HTML code, and achieve the desired display. But this can be done only by trial and error, and there is no guarantee that your tweaked drop cap would look OK on a different device, or even under different settings of your eReader.

Anyway, Atlantis will not save vertical offset for drop caps in HTML/EPUB anymore.

[Alan]

Thank you rstroud for the advice. It is good to know that the font point size is the width of the Em Space.

Alan

[Moonlight]

In 4.3 (beta) bullets (symbol code in MS Word: 8226 decimal respectively 2022 hexadecimal) are no longer displayed:

Version 4.2:

Bullets.jpg (15.74 KiB) Viewed 339641 times

Version 4.3. (beta):

Bullets missing.jpg (22.12 KiB) Viewed 339641 times

[admin]

Could you please be more specific: not displayed where? Do you have a document file that version 4.3 does not display correctly?

[fergch]

Another small problem is that writing time is now a bit hit and miss. A document that has writing time showing in the status bar is visible, but cycling through open .rtf documents results in the writing time disappearing, then it is gone for all documents, even the one that had the writing time present and displaying.

The status bar sections have dynamic widths. Atlantis may make them wider to accommodate current stats for the active document. You might wish to disable some sections of the status bar to free more space for the sections you actually need - choose "Tools | Customize | Status Bar...".

Is, or will it, be possible to re-order the status ber selection, so in the window view (which is my preferred way to work) the item chan be selected to show, and the ones that cannot fit in the windowed view will be exposed in the full screen view, in a future release?

After I made the comment I realised whe items were visible in a full screen, but I had noticed that one that was visible at the right hand end on one document got lost in cycling through several other open documents (.rtf) and back to the first.

Thanks

[Moonlight]

Could you please be more specific: not displayed where? Do you have a document file that version 4.3 does not display correctly?

Yes. It's an rtf-file (converted from a doc-file). When opening the rtf-file in Atlantis version 4.2 the bullets are here. When opening the same rtf-file with version 4.3 (beta) the bullets are missing.