sfriedberg

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?

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.

I would like to generalize the request made in the referenced thread from "article end". It is not at all unusual in magazine work to have a glyph at the bottom of a string of linked text frames. The glyph at the end of the string indicates the end of article, while a different glyph is used for all frames except the last to indicate the article continues. The glyph is usually typeset in the last line of text, right justified with the edge of the frame. Most of the discussion in the referenced thread has revolved around manually placing or pinning a glyph or image at the end of the text flow. These techniques become more laborious when intermediate frames also carry "continued" glyphs. I'd prefer to replace all the manual placement with decoration properties on the text frames, to be captured when making a so-decorated frame is made into an asset, or when a text frame style is defined. While "at end" is most common, it would be good to allow "at top" decoration as well, giving four options each of which could be left blank or decorated with a user-specified glyph (or symbol, ideally): At top of first frame At top of linked frame other than the first At bottom of last frame At bottom of linked frame other than the last

The usual trick, which is not specific to Affinity products, is to manually wrap your design so that the seams run down the middle of your view. Then you can edit the design across the seam to make it look the way you want. For a 1D wrap like a can label or tape repeat (a seamless tile would be a 2D wrap), get the basics of your design the way you want them. Then make a couple of copies and offset them left and right so their right and left edges align. Edit these copies. When you get the seam looking good, apply the changes from the copies to the original. Then repeat the copy-and-offset to doublecheck that things look good in the finished design. Once you get adept at this, you can actually start out building the design at the seam. Once you have the ends of the wrapping pattern worked out across two blanks, move them to the appropriate places in a new single blank, then fill in the middle of the design.

Does the text font contain the appropriate emoji character? If not, find and install an appropriate font, and change the style of the text you inserted to use that font. If the character is not in the assigned text font, where do you expect the displayed glyph to come from?

@pauldev, How extensive are your Scribus files? I explored Scribus for a while and found it quite limited and inconvenient. It was easier for me to bring my original text flows and images into Affinity Publisher and do a new layout from scratch than import the Scribus files. But I was only dealing with a small number of 5 to 20 page documents.

Unfortunately, scaling a vector is not the same thing as offsetting a vector. For a simple shape like a circle or a square, you get the same results. For text or any object with some concavity, the results are very, very different. Creating contours in CorelDRAW is something I do reasonably often, and it would be nice to have the capability in Affinity Designer.

It's already been mentioned above, but when I first heard of variable fonts my immediate reaction was "Are they reviving Multiple Master fonts?"

I'll do an edit on the original posting. The title is correct.

Interesting. I get a popup that says "Assets cannot contain embedded documents" when I try using SVG, which is what I have been working with exclusively the last few weeks. JPG does work. So if you (or the devs) prefer to refine or rephrase my request along the lines of "Allow assets to include anything that can be dropped into, or pinned into, a frame", that's just fine with me.

Let's carefully distinguish between an image being an asset, and a frame containing an image being an asset. At the moment, the latter is prohibited, and I am requesting it.

In AffPub, I want to be able to create an asset like a frame with an embedded image or other "external" doc. I don't care (much) about linking the asset to the original external document; embedded behavior would be fine. I can create assets with text, assets with drawings, but not assets with images.

Old Bruce, I am sure that John Hind is asking for user defined fields, not just repurposing the fixed set of existing fields. In your example, what's going to happen when the user repurposes Revision and then wants one more field?

oneearth, I'm not sure whether you are reporting a bug or a feature. If you unlink text frames, the text flow stops flowing into the frames after the link you remove. It shouldn't get deleted. If you relink the last frame to a new frame, the text will continue flowing. So, it's by design that when you break a link, the text no longer appears in the frames that previously followed the link. But the text isn't deleted. Now, if you found the text is actually deleted, that's a serious bug. And if you want the text to remain in the now-unlinked frames, that's a feature request. Essentially, you want one body of text to flow through two unrelated sequences of frames, with the start of the text in one sequence not the same as the actual start of the text. I don't believe Publisher can use one body of text in two sequences of frames (without duplicating the body of text). And I don't believe Publisher can start a visible text flow at any place but the start of the body of text. So, two new basic features plus the feature of "if I have a body of text flowing through linked frames and remove a link, make the body of text flow through both remaining sequences of frames and offset the visible start of the text in the 2nd sequence so that it looks the same as before I removed the link."

I'm several months late to this thread, but I would add that CorelDRAW, as one example, lets you deform the curve between nodes with the node tool (essentially solving for simultaneous changes to the handles of the nearby nodes). If you want to add a node on the curve, in CD it is a double-click, not a single-click. So you don't accidently get one thing when you intended the other.

Completely agree that the original size needs to be directly accessible, not something to compute using a calculator and current/original DPI figures and current size. Need to be able to reset to (exactly) the original size, and any % or scale factor readout should be in terms of the original size. It's OK if applying a % or scale factor in Transform panel is relative to current size, once you have the capability to reset to original size.

This thread is relevant to that problem. The discussion got a bit side-tracked, but the essential bit about input line breaks being treated as paragraph breaks, and how to deal with it, is clearly stated

I suspect he means like a decoration applied at the end of the last text in a linked set of frames according to a style, not manually placing a dingbat. Something very similar would be a decoration applied at the bottom of every linked frame except the last one. The Economist magazine uses this house style to indicate that an article is continued.

Locally high contrast, lots of color saturation, so you might play around with histogram equalization, excessive sharpening and color adjustment curves. Don't expect to get "the look" with a single layer of adjustment. You will probably need to blend several things together.

Affinity Publisher is not even remotely close to that at the moment. It's not at all clear that Serif even want to take the product in that direction. But today, there is no scripting support, no data merge, and only a paltry handful of hardcoded fields/variables. Not possible to do what you want with the current release.

When files get new name extensions when downloaded from the Web, it is sometimes a sign that the web server is associating the wrong MIME types with the files. If the behavior is different with different client browsers or operating systems, there may also be some dependency on the client's "open this sort of file with that application" settings.

You guys may want to weigh in on this existing thread, too ( )

+1 Every publishing program that exports PDF should support this.

I am running light mode, but it also has some deficiencies in color/lightness contrast of adjacent or superimposed elements. Case in point: the fold/unfold triangle "twiddle" on an Assets panel subcategory title bar.

😁 Ah yes, rockets, machine guns and either (can't recall the movie) RATO units or smoke dispensers on an autogyro. This is like mounting armaments on a Volkswagen Beetle, or more accurately a Piaggio Ape. Nice illustration. I like the stylized shading. Reminds me of illustrations in many textbooks and kid's "all-the-world's-something" books. Given the age, those illustrations were almost certainly air-brushed, either from scratch or over a photo reference.