Support place or paste of plain text without paragraph breaks

[sfriedberg]

I do most, if not all, of my text editing in a text editor.  Not a word processor.  A text editor.  No styling, no formatting, just text.

As a practical matter, lines in the text editor are broken at about 70 characters to make navigation within the file practical.   These line breaks are encoded as new lines '\n' in Unix/Linux environments, and as carriage-return + line feed sequences in Windows environments.  I don't know about Mac environments.  They are not paragraph marks any more than the carriage return on a manual typewriter signals a new paragraph.

When I bring text into Affinity Publisher from the text editor, either by cutting and pasting, or by writing out the file and importing the file, every single one of those broken lines gets converted into a paragraph.  This is extremely inconvenient.  First, the explosion from single lines to a series of paragraphs makes the pasted text take up about 3 times as much space as needed, pushing things way out of position.  And then all the spurious paragraph breaks have to be removed.

I want a mode where I can bring plain text (MIME text/plain) into AffPub without having to clean up every single line break.  If that's a Paste Special instead of Paste, that's fine with me.  If the line breaks come in as line breaks, that's better than paragraph breaks (since the result isn't spread over 3 times as much space as it should), but I would prefer a mode where single line breaks are removed, and multiple adjacent line breaks are converted to a single paragraph break.  Sometimes I do want to preserve line breaks, as when pasting examples of computer code (or poetry, or bibliographic references), so Paste Special with some options would be nice.  But even when I want to preserve line breaks in plain text, I don't want them converted into paragraph breaks.

Please note that I mentioned a specific MIME type.  Copy&paste and drag&drop in modern desktop environments support multiple clipboard data formats, typically identified by MIME type.  When you copy from a word processor, it probably offers up two or three different formats to a prospective paster.  I don't want anything to change for MIME text/rtf or text/enriched or any other richer or more structured data format.  I just want MIME text/plain to be handled in a less aggravating fashion by not treating a line break as a paragraph break.  A line break in text/plain is not a paragraph marker.  MIME text/plain (RFC 2046, section 4.1) does not have any concept of paragraphs, and explicitly does not give a line break any interpretation other just a line break (section 4.1.1 specifically, and notice how text/plain is contrasted with text/enriched), and I consider the current behavior to be actually a bug, not just a missing feature.

Now, if Find&Replace had an option where I could apply it to just selected text, I could clean up a plain text paste without much labor.  But it doesn't have that option, and manually inserting unique markers at the top and bottom of a region of recently-pasted text to enable writing a regular expression that only matches within the region of interest does not fall into the realm of what I would call "convenient".  However, if you want to give Find&Replace that option, then I can deal with it myself.

If it matters, I am working on Windows, where the relevant clipboard data format for MIME text/plain is CFSTR_MIME_TEXT.

[Old Bruce]

18 hours ago, sfriedberg said:

I do most, if not all, of my text editing in a text editor.  Not a word processor.  A text editor.  No styling, no formatting, just text.

As do I, my text editor has a line wrap function (called Soft wrap) so I only have to use a return at the end of a paragraph, check to see if yours does. I use the Mac only BBEdit. 

I think you and I have different definitions of plain text.

18 hours ago, sfriedberg said:

Please note that I mentioned a specific MIME type.

Isn't MIME an email protocol? I have found that email is a lousy source to copy from when working with Publisher unless first converting to plain text and I would suspect that MIME is also a poor choice.

19 hours ago, sfriedberg said:

Now, if Find&Replace had an option where I could apply it to just selected text,

Most everyone wants this. I find it hard to understand why this wasn't available from the very first incarnation of Find and Replace.

[walt.farrell]

45 minutes ago, Old Bruce said:

As do I, my text editor has a line wrap function (called Soft wrap) so I only have to use a return at the end of a paragraph, check to see if yours does. I use the Mac only BBEdit. 

There are also Windows text editors with that word-wrap function. Notepad and Notepad++ for example.

[sfriedberg]

8 hours ago, Old Bruce said:

As do I, my text editor has a line wrap function (called Soft wrap) so I only have to use a return at the end of a paragraph, check to see if yours does

Isn't MIME an email protocol?

The editor (vi) has its roots in the late 1970s or very early 1980s.  The modern version (vim) will soft wrap, but I don't use that feature for several reasons.  1) You have to use a different set of navigation commands to move by display lines instead of actual lines, and I am not going to retrain my 30-40 year muscle memory just to humor Publisher.  2) When you send the resulting file to a printer, you get an unreadable mess. 3) I have an existing tool chain, and the files I produce with vim integrate nicely with that toolchain where softwrapped files cause problems with some of the other tools.

No, MIME is not an email protocol.  Email is where MIME types were first introduced, but they are now used everywhere, including desktop clipboards, web servers, and any application that does its own copy/drag data sourcing or paste/drop data sinking.  Industry standard for identifying data formats.  MIME type "text/plain" means ASCII text, where line breaks are line breaks and there is no formatting, styling, embedded type codes, paragraph marks, escape sequences, interpreted characters, or anything except ASCII text.  What do you call plain text, Old Bruce?

[Wosven]

If you want to keep on using vi, perhaps you need to insert and third app between vi and APub to convert your end of line properly.

[trichens]

The issue here is the differences between Unix and Windows and they way they handle C/R and L/F use.

I use SublimeText ot Notepad++ for all my text editing and that does a soft-wrap at the end of the "on-screen" line - I can set this wrap at a particular character.
The files it produces have no line breaks in the text unless I actually ask for one by pressing C/R ( and/or L/F).

The problem you have with your vi edited files is that you are manually adding a L/F - and I'd imagine a C/R - at 70 characters - so this gets picked up as the end of a paragraph.
What happens if you carry on typing without adding a line break?
The only time in recent years - and that was around 20 years ago - I have come across this before the editor was breaking the lines at around 60 characters and when the resulting file was loading into other applications we got a C/R and L/F and so a new paragraph. We had to do a find and replace to get rid of then.

If you are using Unix type tools can you run the text file through sed or similar to remove the extra C/R characters?

There's a unix2dos tool that may produce a suitable files or you may find vi can do this with the following from the vi command line

:%s/^M//g

[Cranky Old Huckster]

This points to a serious issue with importing text into Publisher that I find extremely irritating. Text import options are missing (or I haven't found them, I just started). InDesign handles this at the outset (see first screenshot). There are also options for importing MS Word styles that you can replace style-for-style as well.

To be able to import long-form text this ought to be a standard feature, especially converting typographer's (aka "curly") quotes automatically.

I imported text formatted with line feeds as well as carriage returns and it was a mess. Using Find and Replace, I was able to delete the double returns, but the line feeds were left in place. InDesign made short work of it with just the dialog box below.

The second screenshot shows the options (I added some, but the ones baked in are pretty thorough) available in InDesign to clean up text. Are there equivalents in Publisher?

If there's a way to do this basic stuff in Publisher, please let me know. If not, I hope it's implemented soon.