Unbolding text affects line height

---

A post originally by @olibclarke:

Also, changing highlighted text to Bold (or italic, but not underline), and then back to plaintext, results in alteration (increase) of the line spacing. This is a bug.
Oliver.

@mz2 Here is a screencast of the glitchy bold/italicizing behaviour - quite often the text seems to become unresponsive to subsequent formatting, as well as exhibiting random changes in line spacing etc:
https://www.dropbox.com/s/su2dlqoym5wxr99/bold_bug.mov?dl=0

@olibclarke I have moved your earlier post to this new thread such as to keep the forum tidy.

@olibclarke: thanks – we'll try to fix this one up. The issue is purely a visual presentation glitch, you need not worry about any alterations to the data having been saved.

This "visual glitch" is still present in 1.0.22.

Also, making a selection including some plaintext and some bold text (and subsequently bold-ing it) results in a situation where the selection cannot be returned to plain text - it is stuck as bold.

This kind of thing really should have been fixed prior to 1.0 - basic formatting, undo and selection behaviour all need to work flawlessly for users to be able to trust a text editor, and none of those things are true right now. Your current users are effectively paying to beta test your product which is not a great way to build a loyal base of customers IMO.

I look forward to seeing Manuscripts improve in the future but right now (although I bought it during the beta because I am very enthusiastic about the approach and the ideas behind it) I cannot trust it enough to commit to writing a paper with it.

Cheers,
Oliver.

@olibclarke thanks for your feedback! If you could send us via support@manuscriptsapp.com a manuscript demonstrating a case where text that cannot be unbolded, that would help a lot. If possible, a quick screencast or a screenshot showing the bit where that happens would help too.

Re: the more general point you raise, we are fully aware of the challenge in this respect and did not venture on this software project that is in scope the biggest I certainly have ever been involved in without thinking this through: writing workflows are determined based on many factors and we totally understand that reliability is a top one. This motivated a long beta program, it also motivates us iteratively improving and polishing and listening. This is the best that a two-man team who also need to eat and pay a mortgage can do on a huge app that took three years to get to a 1.0, and I believe we give great value for our early adopters with purchase prices like $19.99, $15.99, or presently during Cyber Week even $9.99. This is also why we have multiple redundancy mechanisms for version history built-in in the document (indeed an infinite version control embedded in the document is to my knowledge completely unparalleled to a word processor like rich text app) and indeed we focus first and foremost on issues leading to potential data loss (this is fortunately not one – it's highly annoying and we'll do our best to get to it of course). But I agree, it all boils down to trust: we do our best to gain it and keep it by listening and improving at a rapid but safe pace. Thank you for supporting our work.

Hello,

Here is a screencast demonstrating the issue: https://www.dropbox.com/s/16k2y7giikwtmk6/bolding_bug.mov?dl=0

Regarding more general issues: I apologise for the brusque tone, I do understand that you guys have limited development resources and are doing your best, and you clearly care about responding to user concerns, which I very much appreciate.

It's just a little frustrating as a user... I bought Manuscripts during the beta at I think $19.99 to support development of the software, and I kind of expected that a lot of these issues would be fixed by 1.0 - and I didn't buy it with any kind of knowledge or consideration of how few people are on the dev team, I bought it because it looked like it had a lot of potential to be a very useful piece of software. I recommended Manuscripts to colleagues (at least one of whom purchased it) because I liked the ideas behind it a lot, and expected that the beta would go on for a while longer, allowing a lot of these issues to be ironed out, which has not yet been the case (although it is clearly improving).

I will keep monitoring how Manuscripts is progressing and report bugs/suggest features when I have the time, but I can't actually use it for writing papers yet, which was what I had hoped to be doing at this point.

Cheers,
Oliver.

@olibclarke: when that happens, does drawing a new selection range help you unbold it? The character styling system is going to be improved still for sure overall, it's also not modal at the moment (in that you can't toggle it on and off if you have a specific position rather than a range selected).

Re: your general point, we offer functionality that to my knowledge no particular app does thus far. At the same time, writing workflows are complex and personal and we get that and we respond to that the best we can indeed. Thanks for your patience.

@mz2 Yes, changing the selection range can sometimes resolve this, though I don't think that is a great solution - if I make a solution and apply bold/italic/underline formatting, repeating the formatting should always toggle it off, no matter what - the basic things must be predictable otherwise the user experience gets frustrating quickly. Incidentally, pressing Cmd+A in the editor seems to change the selected section, rather than selecting all text as expected - is this the intended behaviour?

Cheers,
Oliver.

@olibclarke oh absolutely, I am just asking to establish details to assist in improving it.

The Cmd+A indeed extends the outline selection as well as that of the editor. The idea is that it reflects the selection in the editor.

@mz2 Ok - but say I have some text selected in the editor. I press Cmd+A. I would expect it to select all the text (either in all sections or just the current one). This doesn't happen - instead it does not alter the text selection in the editor, but highlights the first section in the left hand panel without switching focus to that section. This is the intended behaviour?

Oliver.

@olibclarke no, it is not expected behaviour (expanding the selection to all that is visible in the editor is expected behaviour) and I also cannot reproduce that. If you could show that with a screencast sent to support@manuscriptsapp.com that would help us a lot in understanding what may be going on (ideally with the document also attached).

@mz2 Sent doc+screencast. Seems to be document specific - select all worked correctly on a random ms word doc imported into Manuscripts, but not on the document I have sent you (what it is actually doing in the editor is moving the text cursor back to the start of the document without altering selection).

Cheers,
Oliver.

@mz2 Just noting that both of the bugs reported here remain in 1.033.

@olibclarke yep, this is resolved in the 1.0.34 update which is pending release.

Select all (Cmd+A) still does not work (checked with the test document I sent you previously).