the program wraps text on the clipboard

[antoxabond]

Hello.
An interesting behavior of the program is observed: when loading a document, for example, "txt", the program transfers the text that does not fit on the page, but if it is copied to the clipboard, the text will also be with transfers that the program itself placed.
For example, it was like this in the original document there was one line:
(1st line) * new advanced settings: FullPathInTitle, UseSysColors (no longer exposed through the Options dialog)
and there are two lines in the clipboard:
(1st line) * new advanced settings: FullPathInTitle, UseSysColors (no longer exposed through the Opti
(2nd line) ons dialog)
Will this behavior be changed in new versions?

I am also interested in whether a TTS (SAPI) interface will be added, similar to the "moon + reader" program. It would be very good if the program read the text.

[GitHubRulesOK]

Depending on the way a file is written and extracted there are many different behaviours and PDF is possibly the worst most variable for such behaviours.

Your comment is about text.txt where the clipboard in & out adds a line feed which is often normal for copied plain fixed width text. here in comparison SumatraPDF is no differett to using the xps in out method for capturing text, line feeds are added when required.

For PDF users internally each leter or a few letters at a time will be on a line but when extracted those internal lines become one or many. Most commonly all the letters at the same height are considered as one line unless there are clear distinct blocks.
It is not uncommon for a "WORD" from a PDF placed on the clipboard to come out as
W
O
R
D
in binary reality each letter is an 8bit word and can be on its personal line even if thats visually the same height as other page characters

TTS is posssible but for SumatraPDF its an issue since most words are not exposed in the canvas, those seen are in effect rendered pixels like images thus would need OCR. its much easier to use MS edge for PDF or TXT read aloud where you can change speed or voice or send to the TV or save as PDF or print or whatever

[antoxabond]

Clearly, this is a feature of the program engine. Simply, for comparison, there is no such behavior of the program in the STDU viewer.
Also then it would be possible to implement TTS at least for those that can be copied to the clipboard as text? Your program is very useful and it would be very nice to have such a function. In other programs where TTS can be used, the ability to use content navigation and open a document from a previously opened place is lost.

[GitHubRulesOK]

I am not the developer just tech support but TTS screen reading should be active via Narrator. Certainly if I place text in the text box (copied from behind the canvas) I can hear the first line then do the second line hence I say it is easier to use the dedicated read aloud feature built into Edge or NotePad etc. where the whole page is shown enblock as text. It is easy to send the selected page to an external app such as Edge for reading out loud without the narrator guff. see parts of #1280 However main discussion is in #321
I have often included in-page TTS in my own enhancements but its VBS or AHK and will only work for selected text blocks, not a whole page of natural speech thus I keep reverting to sending the Page to the best system reader =Edge, It will accept text files too. Some of those others such as DSpeech by Dimio have ability to change line feeds has built in translation, text look-up etc. http://dimio.altervista.org/dspeech_sample_eng.mp3

There are several better screen TTS systems that I found work with built in OCR but the other primary one SumatraPDF has occasionally tried supporting ( NVDA does not work well with image pixels of text)