garrettm30

I’m so totally stoked about this beta. I have spent a couple hours poking around, and I can say that this beta is further along than I expected. I have high hopes that this will in time replace Indesign for us (a small publisher), and it looks well on track. Among several features that wowed right away and other "missing features" that I can work around, the one thing that stood out for me is the lack of GREP searches. In Indesign, I have a small series of GREP searches that I have saved over the past years, and I run nearly everything through them. A couple minutes on a typical file, and I have made several hundred changes. When I work on a book, the changes are in the thousands. (Note: I publish in French, and French typography relies heavily on non-breaking spaces; these GREP searches help me rapidly put them where they ought to go.) While you're there: being able to save the searches as presets would be ideal. And as not everyone is familiar with GREP, a few pre-saved searches would help provide them immediate use: remove multiple spaces, remove trailing space, etc.

I’m surprised how little discussion there has been around the forum about this. This is not exactly a workflow problem is as it is a more fundamental issue of quality of output. In cases where paragraph justification is required, InDesign and others like it will simply produce superior results in this regard than software that does not have some sort of multiline composer. I’m surprised more people haven’t requested this feature. For me, as I do plenty of justified text, often in narrower columns with nonbreaking spaces (that is, where a basic single line composer shows its weaknesses), I could not recommend taking such a step backward from what we are able to do now in InDesign. I would have thought that this kind of thing would be priority for professional layout software: naturally the first version of any software will have fewer features, but one would hope that it would do its few things well. As far as justification, it is more like Word than InDesign**. However, I can be patient with the developers in this: whereas I would think this to be a core feature when starting a new app of its kind from scratch, I suppose the reality is that Publisher is not truly starting from scratch: it is building on the foundation of Affinity Designer and perhaps to a lesser extent Affinity Photo, and clearly a multiline composer is far from a priority in those apps. With those as its foundation, I can understand that a multiline composer might not come right away. I just hope Serif understands how important it is for the quality to truly shine. Without it, I don’t think I could use Publisher for work requiring significant amounts of justification. **To be fair, Publisher does currently handle justification at least somewhat better than Word, in that it has customizable word spacing and letter-spacing, so it’s got at least part of the solution, but the gappy spacing still remains.

I just stumbled onto this thread, and I am happy to see fellow Antidote users in this forum. I suspect we are a rather small minority, so I never even bothered mentioning it as a feature request. Although I don’t feel right claiming this is a “must have” feature, for my own work, I don’t know what I would do without it. I think the impetus for integration rests more with Druide than it does with Serif (although it would surely require Serif’s cooperation). On the Antidote website, they do invite this kind of feedback: They may not be interested in integrating with a beta, but once Affinity Publisher goes public, I do intend to contact them. Here’s the link for anyone interested: https://www.antidote.info/en/contact (English) https://www.antidote.info/fr/contact (French)

The discussion of what to call this has been interesting to me (I’m just now catching up on the thread). I am familiar with regular expression from my experience in programming (predominantly PHP, which does use PCRE). In the last few years, I have come into the publishing world, where I noticed InDesign calls searches by regular expressions “GREP” in its Find-Replace dialog. I have known there is technically a difference, but I have not really paid attention to what it is. When naming this thread, I supposed there were many more readers familiar with InDesign than with programming, so I named the thread according to what I supposed people are familiar with. If Affinity chooses to add this feature and call it “Regular Expressions,” then perhaps that is the best and most consistent, but honestly, I’ll be glad to have it even if they choose to call it “GREP” even if slightly inaccurate, or even “Geeky Super Search.” As to flavor, sure, I would be happy with PCRE, as that is what I know. I have occasionally come across features that work in regular expressions in PHP that didn’t work in InDesign GREP—I can’t remember what it was, maybe negative lookbehind, or some such. However, I suppose that we most likely would get whichever flavor is built into the programming architecture in which the apps are written. I only know web programming, so I am guessing here, but I would think that if they use the functions provided by the programming languages they are using, then it should be a very easy thing to implement. And just for fun, here is the resource I use for building my regular expressions, both for use in InDesign and also for programming. Perhaps some of you may find it as useful as I have: https://regex101.com

Are footnotes and endnotes currently possible (besides manually creating them, of course)? I haven't found them so far. If not, this is a feature that I think would be widely used. I suspect it may take some time to get right if it is not yet under development, so I would understand if it is not a day-1 feature.

The text in that file has hyphens and line breaks hard coded (by that I mean actually typed as text). In the screenshot below, I made this apparent by reducing the width of the text frame and observing how the text reflowed. On the first line as visible in the screenshot, the hyphen after écono is a soft hyphen, added by Publisher's hyphenation. The hyphen and the line break on the second line (after "mi") are actually typed into the text, and they will appear no matter where the text flows. I don't know where they came from (perhaps you copied from a PDF or other source where hyphens or line breaks were already applied), but you can just delete the extra hyphens and line breaks.

I think there is some misunderstanding here. It is true that Affinity is working within the standard print dialog box (which sometimes I wish Adobe would also do -- I still can't send jobs of more than 999 copies, even though I can in basic apps like Preview). BUT, they are using the application specific section. The "Range and Scale," "Document Layout" and "Bleed and Marks" are specific to Affinity Publisher. This is not dependent directly on either what macOS provides or the printer driver. Notice these comparison screen shots of the dropdown printer settings menu of Affinity Publisher, Affinity Photo,TextEdit, and Preview : In all of these screenshots, the printer I selected was the same, but the top section differs according to application. Or compare the above to this screenshot, which is Affinity Publisher printing to a Xerox (the ones above are to a Canon irADV): It is an entirely different printer, so naturally the print driver features (middle section) are different. However, the app-specific section that Affinity provides is identical. The Document Layout section and the other two are custom by Affinity. If you need more convincing, notice this print dialog box from Affinity Publisher printing to a label maker: Again, that is an entirely different print driver, but the same three options specific to Affinity are there. You can be sure that it wasn't DYMO who gave us the option to print booklets onto a roll of 1⅛ x 3½ labels, yet the option is there--because Affinity provides that option, independent of the print driver. I appreciate this thread, because it has forced me to think it through, and in the end, I think Affinity is making the right choice to work within the paradigm of the operating system. (I would be interested to know how this is handled in the Windows version.) Sure, a few of the options could be fleshed out (for example, creep in booklet mode - and what is the difference in book and booklet modes?). But those things can be added within the framework that Serif has already established in these betas, and I think working in the standard dialog box is the wise choice. InDesign's implementation tries to rewrite their own print dialog box to some extent, and despite what must have been a massive effort, it is buggy. To give just one example, with the latest drivers for our printer, I have to save as PDF or PS and then print from the lowly Preview instead of printing directly from InDesign. I must do this anytime I need both offsetting and a cover page taken from a different paper source. From InDesign, if I try to use those settings with multiple copies, it sends the job as though it were one really long document rather than multiple copies of a normal document. It takes a long time to send to the printer (like half an hour), and then when it prints, it treats it as one really long copy, with exactly one cover page and offset exactly one time. I have used these same settings in InDesign with previous drivers without this problem. But those are the kinds of things that happen when they try to go maverick. To give another bizarre example, Safari's print dialog box is also somewhat custom. Although it is styled to mostly look like the standard implementation, it does not respect Apple's own convention. Not only are the options moved around from everything else, but there is a persistent bug that I reported more than seven years ago—when I was on a different computer, different operating system, and I had a different job in fact with different needs—where it will not respect paper margin settings. To specify a margin in Safari, you have to first go to System Preferences, create a custom paper size with the desired margins, and set that paper size to the default. Thank you, Serif, for not messing with these things.

I use InDesign's Print Booklet regularly for a few hundred of our publications, so I would be happy to see something more substantial in Publish. So in that sense, JDW, I get your point--I too would love to see that feature. However, I have done some testing, and I am able to get reliable booklet printing with Affinity Publisher as it is now. (It is actually one of the first things I tested, because I knew I would need to be able to print booklets.) Creating a proper booklet printing interface is probably a rather large task, especially once you have to deal with so many different printer types. I can imagine that it could be rather massive. I really don't think we could rightly expect that it should be ready for any of the version 1 releases, especially since they have a number of other essential (or as I read it so often, "show-stopper") features to implement. If Affinity Publish in its first release meets my needs otherwise but is lacking in booklet making, I would be happy to buy proper imposition software and still use Publisher for layout rather than continuing to hemorrhage money to Adobe for InDesign. Dedicated imposition software can be more capable than even InDesign's Print Booklet feature, so I might end up preferring it. Summary: I would like dedicated Print Booklet feature, but it is my opinion that it is more of a luxury than can be expected in the first version of $40-50 software.

I have tested your file, and indeed it seems that the calculation for wrapping around edges needs to be tweaked. In the screenshot below, I have opened the file and replaced the text, on the the left, with a letter that descends below the baseline, and on the right, with a letter than ascends above the cap height. I have also selected all of the text to make the text lines more apparent. I see that in the top of the circle, it appears to align perfectly to the text baseline, as you can see that the tail of the p dips into the outer circle. At the right edge of the circle, it aligns perfectly with the left edge of the text bounding rectangle. And on the bottom, it appears to align perfectly with the cap height of the line of text, as you can see that the acute accent on the É is crossing into the outer circle. All of these things are probably just what need to happen to appear aligned correctly. It seams that it is the transition from each cardinal direction that it gets progressively worse until about 45°, and then it starts to get better again the closer it gets to the next cardinal direction. Or to describe it differently as though the circle were a compass, it is best aligned at north, east, and south, and worse at northeast and southeast. Perhaps that is a helpful clue to the developers to see where the problem is? Or maybe not, but that's all I've got.

@imcath, it sounds like you are looking for a word processor rather than desktop publishing/layout. It's true that there is overlap in what each category can accomplish, and I think it might make for an interesting discussion about the philosophical differences between the two. For the purpose of this response, I think it is sufficient to note that the two categories are indeed different in both their market and their workflow approach. Affinity Publisher seems to be positioned to compete in the desktop publishing crowd (along with apps like InDesign, QuarkXPress, Microsoft Publisher) rather than the word processor crowd (Microsoft Word, Writer in OpenOffice). Despite the overlap in some functionality, Affinity Publisher is not positioned to compete with word processors; it isn't really in the same category as Apple Pages (not iPages), so I wouldn't hold it against them if it is not the Pages replacement you were hoping.

I would also like to suggest the "Balance ragged lines" feature. This is something I use in almost every publication I produce. For those who do not know what I am talking about, this is a feature from InDesign. Imagine a center-aligned heading that is just a bit too long to fit on a single line. Normally, this would mean only the last word or so would get bumped to the next line. Such as this: The quick brown fox jumped over the lazy dog Balance ragged lines would instead display the following, without any need for forcing a line break: The quick brown fox jumped over the lazy dog

I am able to use this and other varient spaces from the mac "Show Emoji & Symbols" menu (pictured below), but I have also requested in another thread that several of these spaces be added to the Insert menu, namely, thin space and hair space. I do use both of those.

From the changelog on 1.7.0.128 I take it that these two fixes refer to my two screenshots above. The spacing as shown in my first screenshot has been resolved in 128. The second (where "body" looks like "bodv") still appears exactly as the screenshot. Note that I have "Font UI Size" set to large in the preferences; this is a Mac without retina display.

Here are a couple of spacing issues when the interface text size is set to large. In the Paragraph studio, the drop down menu that says "Body" overlaps the subsection below it: In the Text Styles studio, the name of the style for currently selected text does not have enough space for descenders (Here "Body" looks like "Bodv").

I think the most promising solution is to take the "image with camtion" that you have already made and save it as a symbol. For me, they take a little getting used to, but I think there is a lot of power there.

In the open file dialog box (File->Open), normally one can start typing the name of a file to jump straight to it. This is helpful particularly in list view when looking at a directory with many files. Currently, some of the letters activate Designer shortcuts behind the Open File dialog box rather than the standard Mac behavior. Here are some basic steps to illustrate: 1. Create a new document; click OK to accept default settings. 2. File->Open; preferably, navigate to a file with many files or directories - they do not have to be compatible documents to illustrate this. 3. Type "T" key - The dialog box does not jump to a file beginning with T. Instead, notice on the Publisher toolbar behind the dialog box that the Text Tool has been selected. 4. Type "V" key - Now the Move Tool is active 5. Type the "C" key (or some other key that does not have an assignment in Publisher: L, O, etc.) - Correct Mac behavior: the nearest file matching that name is selected. For what it's worth, I tried similar steps in the current Designer, and the standard Mac behavior is respected.

Yes, that is the bug I described. Your video may be helpful to show the developers what I tried to describe above. There is a workaround: don’t change it by editing the style directly. Pick a paragraph of that style, and edit its minimum score from the paragraph studio. Then with that same paragraph still selected, go back to the styles, right click on the style, and “Update Style” to match that paragraph.

I second that suggestion. I would use optical kerning often if that were the solution offered, but personally, I think giving us a way to manage custom kerning pairs would be the superior solution in most cases, and perhaps easier for Serif to implement.

That's interesting (and I occasionally do use Greek, but never yet in Indesign for professional work). So does optical kerning solve that problem?

That is an interesting procedure I didn't know about. Thank you for that. Generally I think that a key command would be much faster, or even having to go to an insert menu with the mouse would still be more helpful. I already switch between French and English keyboard layout multiple times a day (using key command of course), but having more than just two key layouts often works out to more frustration than it is worth, as it no longer is just a simple toggle back and forth.

Here are a couple suggestions concerning three whitespaces that I use frequently. First, Thin Space (non-breaking), Hair Space, and Right-Aligned Tab are the three white spaces I am used to using that are not currently in the Text->Insert menu. Adding them to the insert menu also lets us assign keyboard shortcuts. (Indesign has a keyboard shortcut assigned for Thin Space and Right-Alligned Tab, but hair space is in the menu without a shortcut, so this would be a win for me.) Secondly, thin space (U+2009) is not rendered very thin in Publisher, particular in justified text. Thirdly, the thin space I need (in French typography, used between several common punctuation marks such as question marks) needs to be nonbreaking. Specifically, this is "NARROW NO-BREAK SPACE" U+202F in Unicode. Indesign complicates matters. It offers a "Thin Space" that it treats as nonbreaking, but it apparently uses "THIN SPACE" U+2009, which in my understanding is not explicitly nonbreaking. When text in Indesign is pasted into Publisher, U+2009 that was formerly nonbreaking is breakable in Affinity Publisher. MS Word also treats U+2009 as nonbreaking, so although I think Publisher may actually be performing according to Unicode spec, it is a sticky situation. To summarize, the hair space and nonbreaking thin space (however you choose to work it out) are needed in my work. I can at least work around by inserting with the Mac Character Viewer. Right-aligned tab can be worked around with other methods, but it is a nice convenience to hit that shift-tab. The first answer on this post on StackOverflow.com, although dealing with HTML as the context, is still very helpful explaining the problem with the nonbreaking thin space for typesetting in French in the digital age.

Your first two suggestions are interesting ideas, but the the third especially, optical kerning support, is an important element in quality output. I find many fonts, even with kerning tables, fail in this respect, where optical kerning does a better job. I find it amusing that Adobe's default font, Minion "Pro," is better with optical kerning for the many kinds of constructions in French such as the very common word c'est.

This may or may not be related - I did download the file you provided and successfully got hyphenation with one change. First, the bug I see: when one edits a style (From Text Styles studio, right click on the style, and choose "Edit 'Style Name'"), changes to the Minimum score under hyphenation are not saved. As a workaround, pick a paragraph that is assigned to that style, go to the Paragraph studio, and set the Minimum score there to 1. Then you can update the style from that changed paragraph. For you, frankwolfraum, you need to set the "Minimum score" to 1, and it will work. To developers: We need some help understanding what minimum score is. Perhaps it is not aptly named. Or maybe this is something similar to the slider in Indesign for "Better spacing" versus "Fewer Hyphens" :

When Text->Show Special Characters is activated, several of the spaces are represented with the same tiny dot as a regular space. For example, nonbreaking space and narrow no break space (U+202F) are identically marked. Since one can’t tell by looking whether white space is nonbreaking or not, this is where Show Special Characters can be particularly useful to distinguish them. I make use of this mode more often than not, and I have a lot of both nonbreaking spaces and thin nonbreaking spaces.