Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Powerpoint 2003: serious editing problems in textboxes that contain multiple paragraphs #4619

Closed
nvaccessAuto opened this issue Nov 11, 2014 · 11 comments
Closed

Powerpoint 2003: serious editing problems in textboxes that contain multiple paragraphs #4619

nvaccessAuto opened this issue Nov 11, 2014 · 11 comments
Assignees
@michaelDCurran
Labels
app/microsoft-office bug
Milestone
2015.1

Comments

@nvaccessAuto
Copy link

Reported by Palacee_hun on 2014-11-11 21:53
Steps to reproduce:
[Open Powerpoint and create a new slide.
2. Create any kind of textbox anywhere on the slide big enough to hold a few lines of text.
3. Enter at least four lines of text and end each line with Enter to make the lines into paragraphs.
4. Review the lines first with the review cursor keys, then with regular arrow keys.
The first line looks okay either way. In the second line you'll hear a 'newline' character at the very left end of the line if you use the review cursor, it looks fine with regular arrowing. In the third line you'll notice two newline chars at the left end with the review cursor. In the fourth line one "garbage" char is introduced at the left end, you'll hear it either way. This garbage char comes from the very end of the previous line. With each subsequent paragraph exactly one more char from the previous line gets introduced.
[[BR]([BR]]
1.)]
Now comes the harder part:
5. Position the caret at the first char of the first paragraph (in our example a single line), and hit Delete.
Everything works fine: the first char gets deleted.
6. Now position the caret on the first char of the second paragraph and hit delete again.
Booom: after looking at the line you'll see the second char got deleted, and not the first!
7. Go on with subsequent paragraphs. You'll find that deletion is one more character "off" with every paragraph!
8. Finally try other editing operations with the caret (insert text, copy to clipboard etc.). You'll see that everything is fine in the first paragraph, but in the second the caret is actually one char "off". In the third paragraph the caret is really two chars off, three in the fourth paragraph and so on.
[the second paragraph onward the caret is actually to the right of the character you hear when arrowing. With how many characters to the right depends on in what paragraph you are.
This is a major issue, it makes editing in a textbox containing multiple paragraphs practically impossible.
[[BR]([BR]]
From)]
This is 100% reproducible with Powerpoint 2003, that is what I use. I don't know whether this is a problem with other versions.
Jaws doesn't produce this at all, editing is fine there.
I've debugged several criticalTextInfo methods in the Powerpoint appmodule, but they work correctly and seem to get the right info from the Powerpoint object model. Now I haven't got the faintest idea where this severe bug comes from.
@nvaccessAuto
Copy link
Author

Comment 2 by jteh on 2014-11-11 23:08
I can't reproduce this in PowerPoint 2010, so it's probably specific to 2003, though it may apply to 2007.

One question:

  1. Position the caret at the first char of the first paragraph

How exactly did you do this? Did you press home or did you move by character? The reason I ask is that even if the wrong character was reported (which is obviously a problem), pressing home should still have taken you to the start of the line.

Technical: At a guess, I'd say this has something to do with CRLF line endings, but offsets not accounting for this. I can't see how our code could be getting this wrong, so it must be some quirk with PowerPoint 2003. The fact that it's not reproduceable in PowerPoint 2010 would seem to support this hypothesis.

@nvaccessAuto
Copy link
Author

Comment 3 by Palacee_hun (in reply to comment 2) on 2014-11-12 00:13
It doesn't matter. The results are the same. From the second paragraph onward, you hear the wrong char even if you move to the start of the line with Home.

@nvaccessAuto
Copy link
Author

Comment 4 by jteh (in reply to comment 3) on 2014-11-12 00:26
Replying to Palacee_hun:

It doesn't matter. The results are the same. From the second paragraph onward, you hear the wrong char even if you move to the start of the line with Home.

Right. However, that's not what I meant. If you press home, then delete, then review the text, was the correct character deleted, even though the wrong character was reported when you pressed home and delete? NVDA shouldn't be affecting what PowerPoint does when you press home, even if it reports the wrong thing.

@nvaccessAuto
Copy link
Author

Comment 5 by Palacee_hun (in reply to comment 4) on 2014-11-12 00:34
Ah, I see. Yes, Delete after Home deletes the first char in the line in every paragraph reliably, "only" the reporting is wrong.

@nvaccessAuto
Copy link
Author

Comment 6 by Palacee_hun on 2014-11-16 22:01
Yes, this is CRLF stuff. The _getTextRange method of TextFrameTextInfo class gets it wrong, when it does string slicing to extract the needed range. As CRLF at paragraph boundaries counts as two characters, the slice indexes point to wrong characters after the first paragraph.
[patched method fixes the problem completely for me, seemingly with no side effects:


    def _getTextRange(self,start,end):
        #First let's "normalise" the text, i.e. get rid of the CR/LF mess
        text=self.obj.ppObject.textRange.text
        text=text.replace('\r\n','\n')
        #Now string slicing will be okay
        text=text[start:end]([BR]]
This).replace('\x0b','\n')
        text=text.replace('\r','\n')
        return text

I hope this is okay for Powerpoint 2010 and such too. If it isn't, you can limit this fix to Powerpoint 2003, or you may choose the "official" route and use the characters method of the textRange object, e.g. like this:


        text=self.obj.ppObject.textRange.characters(start+1,end-start).text

I've experienced some very subtle side effects when trying this alternative, mainly around the last line and it seems moderately slower, but that's just an impression.

@nvaccessAuto
Copy link
Author

Comment 7 by jteh (in reply to comment 6) on 2014-11-16 22:16
Thanks for the debugging/patch. One question:

Replying to Palacee_hun:

As CRLF at paragraph boundaries counts as two characters,

I assume you mean CRLF is two characters, but it only counts as one offset as far as PowerPoint is concerned?

@nvaccessAuto
Copy link
Author

Comment 8 by Palacee_hun (in reply to comment 7) on 2014-11-16 22:25
That's it: it's two characters in the returned text, but Powerpoint 2003 returns all its offsets (e.g. the selection offsets) as if it were only one offset.

@nvaccessAuto
Copy link
Author

Comment 9 by jteh on 2014-11-17 04:50
Too risky for this patch at this late stage, but let's make sure it gets into 2015.1.
Changes:
Changed title from "Powerpoint: serious editing problems in textboxes that contain multiple paragraphs" to "Powerpoint 2003: serious editing problems in textboxes that contain multiple paragraphs"
Milestone changed from None to 2015.1

@nvaccessAuto
Copy link
Author

Comment 10 by Michael Curran <mick@... on 2014-11-19 03:47
In [456adaf]:

Merge branch 't4619' into next. Incubates #4619

Changes:
Added labels: incubating

@nvaccessAuto
Copy link
Author

Comment 11 by mdcurran on 2014-11-19 03:48
I've tested this with PowerPoint 2003, 2010 and 2013 and all works well. If someone could verify with 2007 that would be great.

@nvaccessAuto
Copy link
Author

Comment 12 by Michael Curran <mick@... on 2014-12-02 01:01
In [ddf54e7]:

Merge branch 't4619'. Fixes #4619

Changes:
Removed labels: incubating
State: closed

@nvaccessAuto nvaccessAuto added this to the 2015.1 milestone Nov 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@michaelDCurran michaelDCurran

Labels
app/microsoft-office bug
Projects
None yet
Milestone
2015.1
Development

No branches or pull requests
2 participants
@michaelDCurran @nvaccessAuto