Bikerbudmatt

Thank you so much for this "hard" information. I may have differing degrees of affinity for various scripting languages, but the complete lack of one has been an obstacle to using Publisher to its fullest potential. Also, I'm tired of screen-sharing from my now-ancient late-2012 iMac to produce specific publications in my now-ancient but miraculously functioning InDesign CS6 installation that supports both full scripting and saved searches. This is just great news, and I appreciate the persistence of the programming team in getting this done.

Yes, and yes. I had to turn back to InDesign CS6 (last version with a standalone license) today to start producing the latest iteration of a long-standing project that requires a RegEx search and replace. First pass to catch all instances of a certain numeric string and reformat it using a character style followed by a non-breaking space to attach it to the next word, then a second pass to catch just the leading instance of that string in each paragraph and reformat it with a different character style. ID has the following features that make this a 1-second task, even on the old iMac that is running it: Fully supported and documented RegEx implementation Find and replace strings that can be stored and recalled globally Full scriptability Extensible interface to allow the script to be compiled in Java and invoked at will And all of that from software that was released nine years ago. Early CS versions could do the same. The reason I had to use ID (and had to do it remotely, because the mid-2012 iMac is in another office) is because I can find no other software that will do what I need and bring the results into Affinity Publisher. BBEdit? Only supports text or markup for output, so the amazing RegEx "Playground" is wasted because it can't provide useful output. Microsoft Word? It would seem like an obvious choice, but support for regular expressions (which they call "Wildcards" but which was a reasonable implementation of RegEx) has eroded to the point where it has disappeared from the documentation. And, since AP doesn't seem to support tagging, either, there's no sense in writing a BBEdit text factory to attach markup tags to text. Lack of tagging support seems especially weird because of all the effort that has gone into the IDML import filter. I'm really hopeful that an LED lightbulb will go off in the developers' heads, because they must be that close to supporting tagging in general. So again, as @michalmphpoints out, we don't need to solve the "which language" problem for Serif, but I for one would really love to retire that old iMac from its production job so it can serve household files for the next 10 years!

It took me a day to learn how to think in points and picas when I was learning typesetting on a Compugraphic machine in 1981. It properly remains the way I spec and set everything I do to this day. That includes Microsoft Word documents, where setting margins and hanging indents in points is so much easier and faster than doing the same in decimal inches. I would probably find metric measurements workable, but they are discouraged in the USA and so they are not a go-to. It doesn’t matter, though—Serif provides enough measurement systems (including yards!) to keep everyone happy, and they are all available on the fly with a single right-click.

Um, there is a solution, and very similar to that used in the <cough> other major publishing application. Point at the intersection of the horizontal and vertical rulers in the upper-left corner of the document window. (If they are not visible, select View->Show Rulers, or type COMMAND/CTRL + R) Right-click or CTRL-click on the intersection. From the contextual menu that appears, select your preferred unit of measurement. Everything from rulers to information boxes will now display in that unit. Unsolicited bonus: If you want to change the "page origin" (the point from which the H and V rulers measure "0"), click and drag from that spot. Again, exactly like the other, captive-subscriber-hobbled application. Finally, know that many of us here in North America very much design and think in picas and points, and campaigned hard to encourage Serif to include it in the program.

Holy cow. I just read 11 pages of opinions stretching back 3 years giving Serif all kinds of advice about which flavor of programming language, how proprietary (or not) that language or languages should be, etc. Tip o' the cap to all of you who have brought nuance to that part of the problem. I have been able to accomplish some amazing tasks over the past 35 years using automation tools. If it wasn't available directly in the application, there were hooks to allow an external tool to accomplish programmatic tasks. Given that some kind of implementation is needed, and that it involves choices, I want to step aside from that detail and state: Some form of scripting would vault AP and its suite-mates into the professional tool arena. It's just not there without it. Some form of macro editing/creation, as with Photo, would ease the pain of text manipulation. Some form of saving find/replace expressions for reuse would make it worthwhile to use RegEx/GREP strings. I list those items from most to least difficult (in my naive understanding). In order of implementation priority, I'd reverse the list. Surely Serif could pick off one or more items from that list and realize a huge gain in adoption (for Serif) and productivity (for users).

And with that answered, I searched the Publisher help for this topic, and the closest I came was the discussion of "Object Defaults." This appears to be too particular and misleading, as @Old Bruce's solution also applies to default panel values and, I presume, anything else that is a default in Publisher. That may suggest a revision or clarification in the Help facility would be in order. Thanks again!

You, sir, are a champion. Thank you!

After searching pretty much every thread that could be related, I've learned the following: A default "space after" value of 12 pts leading between paragraphs appears to be an intentional choice on Serif's part. There is a school of typographers who believe that this is a good thing for long blocks of text, and I respect that. There appears to be no easy way to change the base style globally (that is, in one's local installation of Publisher) so that the "space after" value is 0 pts, or any other value but 12 pts. I accept the first two points, but want to know if the third point is true. Is there any way to change the base style so it applies globally to every new document that is opened? Thank you for your thoughts on this matter.

This is a major update in my book. I have hesitated to commit to Publisher because of my large library of InDesign CS6 files that still need tending. After seeing: The short work that Publisher made of ingesting an IDML file; and The fact that I can now save that ingested file as a template I am blown away. THANK YOU for this. I have used ID since its initial release in the early 2000s, migrating from PageMaker. I have pushed it close to its limits, and have depended upon it for jobs small and large. I have had to freeze my MacOS version at High Sierra to accommodate it, at the expense of updating other applications. With this capability, I can virtualize High Sierra, safely move to the latest system, and run CS6 for exports. For fun I opened an IDML file in BBEdit. After seeing what the IDML package encompasses, I say "hats off!" to the Affinity Publisher team. Well done!

Congratulations to Serif and the Publisher team on release! In very early use, I'm noticing that Publisher 1.7.1 is not seeing all the fonts installed on my Mac. I don't notice a particular pattern, though I haven't yet looked hard. In particular, "Book Antiqua" is MIA, though it is verifiably active on my Mac. (2017 MBPro, High Sierra.) Thank you for the release.

Would love to do that. Can’t find the special request, but lots of individual threads requesting this! Point me toward the thread you’re seeking support for.

Thanks, of course. I’ve been asking for this for 2 years and want it to be implemented.

I have previously requested this for Designer and Photo, but accepted that pixels/points was possibly adequate for most folks' needs. But I'm aghast that Publisher does not support Pica & Points as a measurement standard. Please implement this in your measurement engine! I understand that picas may not be used in Europe, but in North America it's a very useful standard. Points alone is not enough. And, thanks for the public beta release!

Two true things: Sometimes people need to vent their impatience. I don't need to be around while they do it. For me this thread is over. (Oh, okay, three, THREE true things.)

+1 to this feature request. And a big –1 to users who argue that everyone should just get used to a black-on-black UI because it's what they think is "correct." On my screen, the icons are very small and nearly indistinguishable when rendered white-on-black, as they are now. The inky void swallows up the details that would otherwise make them easy to identify. And thanks MEB for highlighting Andy's video bit, which seems to show…yes, an adjustable UI!

The other Point (I like the oblique there!) is one of those things that got carried forward for backward compatibility with legacy measures. I still have some metal rules that are marked in traditional point increments. By the time you get to measures like 36 Picas, there is a noticeable difference between the two. As one example of how an identically-named convention could be handled, I took a look at InDesign's "Units & Increments" dialog. Adobe arguably set the 72 pts/inch standard when they introduced the PostScript language, so they have an editable pop-menu with two hardwired selections: "PostScript (72 pts/inch)" and "Traditional (72.27 pts/inch)". But, you can also define a point to be ANY arbitrary factor/inch. That suggests to me a powerful idea: would your engine be able to deal with a measurement system that allows the user to define their own measurement scale? I'm not sure you'd really want to get in to that, and you'd have to set some boundaries to avoid blowing up the app, but I'm wondering if the app is still "young" enough that you could add this without crossing a whole bunch of dependencies? And all of that being said… I'd be happy to see a PostScript or digital Pica/Point measurement in the 1.6 release. Thanks Ben!

Well, yes. The point is the base unit of a pica. So by definition there are two different references for points.

If I were confined to just one, though, I'd ask for the digital "DTP" pica, 4.233mm or 0.166 in. 12 points to the pica, 6 picas to the inch, 72 picas to the foot are very convenient in countries that have not yet converted to the metric system.

Ben, since all three have a defined reference point, why would you not want to include them? Yards and metres are wonderful units to include for drawing and drafting. But, points and picas are bread and butter for typography. (I had to go back to my original post to recall that I recommended at least the American and "digital" simplified pica. But there's no reason to exclude the Didot pica.) Bumping my original request and advocating that it be implemented in the next revision. Thanks!

Agreed. I was used to working with professional front-ends driving precision equipment—starting with film-strip fonts and later some of the earliest imagesetters rasterizing type with CRTs or lasers directly onto film. PM was primitive compared to $100,000 (and up) composing systems. BUT…it was able to produce complete page layouts, including graphics, at a sliver of a fraction of the cost of one of those systems. They were not the pinnacle of typesetting perfection, but they were the practical expression of the WYSIWYG GUI that Lisa and Macintosh popularized. I've learned and forgotten more markup languages than I care to remember. But Pagemaker and FreeHand were two monuments in the evolution of graphic arts, and need to be respected for their historical significance. (And with the other poster above, I made money on them for many years, until one was extinguished and the other was no longer viable.)

Agreed on the drop caps feature—it was primitive and out of control. Wrong apostrophes came from wrong typists. Since I came from an environment where quote marks were keyboarded as seen (no such thing as a "double quote"…that would be two keystrokes of the open quote symbol), it was always interesting to see how Pagemaker would import and interpret so-called "typewriter quotes." Sometimes it worked, sometimes it didn't. But, Oval, you happened to pick on two features that did not exist elsewhere in the DTP layout world when they were introduced. Of course they were not polished. But in the late 1980s a lot of people started making a living with those tools, and a lot of other people found themselves adapting to new workflows because of them. Would I say Pagemaker is a great tool today, in comparison with what's available? Absolutely not. But much of the reason that it became a "horrible" product has to do with Adobe gobbling up the Aldus corporation, freezing Pagemaker's development, and then leaving it on the market way too long. It was problematic for long-form publishing, and had its quirks, but its many competitors were always chasing its feature set. And honestly, for this discussion, the main thing is integration of digital sources into a layout. Getting that right was a huge Pagemaker strength. It allowed artists, copywriters, and editors to do their work and then submit it to the layout artist working in Pagemaker. That's one of the crucial functions that Affinity Publisher has to get right.

PageMaker (which I first used in v1.2 on a Mac 512KE) was not IMHO a "horrible" or "terrible" product. When Aldus first published it in the mid 1980s there was nothing else like it. I came from a Compugraphic shop where I set galleys on photo paper, which then went to the layout guy, who waxed and pasted them down on boards with non-repro-blue guidelines. Corrections were 2-line slugs that got tipped in over the typos. Photos were indicated on the boards so that they could be shot separately with appropriate cropping and sizing, then stripped into the galley negatives. The negatives were used to make plates. And THEN you could go to press. PageMaker's great (and revolutionary) strength was that it integrated all those elements onto a single virtual pasteboard, and did it all with a mouse click. It was "PageMaker the Horrible" only in the sense that it went through the printing industry like an scythe and eliminated the need for many, many crafts that were part of an older established workflow. What I found horrific was Adobe's purchase of Aldus, which was more an attempt to eliminate FreeHand as a competitor to the truly horrible Illustrator (I'll retract that statement only if someone can explain to me why Illustrator STILL needs at least three different anchor-point tools for editing when FreeHand could do everything with a single, intuitive tool). When the rights instead went to Macromedia, Adobe eventually gobbled them up as well, and of course killed FreeHand. Instead of suffocating PageMaker, they put it in a development-free zone while they spent several years building InDesign from scratch. They allowed PageMaker to stay on the market, essentially a mid-1990s version, so that InDesign would shine in comparison. (And I confess, I'm a daily InDesign user, and overall it does not get in my way.) When PageMaker could no longer keep up with even the mediocrity that is Microsoft Publisher, THEN it looked horrible by comparison. But, I lay all that out to make this point: PageMaker excelled at source->layout integration. And, that's what APub needs to do. That's incredibly difficult to get right, because so many elements are out of your control. Affinity should not release a product until it can import and output files at least as seamlessly (for its time) as PageMaker did.

I am already smitten by Designer and Photo! I have worked with digital design apps since the late 1980s, starting with the 1.0 versions of Freehand, and PageMaker, and with Photoshop since the early 1990s. I see these as viable "next steps" for my current CS6 suite, which is now pretty much frozen in time. Since I'm mainly a "type" guy, one missing feature that stands out for me as soon as I open the apps is an option to show measurements in picas and points. It may not be as important with painting and drawing programs on their own, but I still work with print publications where it really is easier (and for me, native) to think of measurements as 12 to the pica, and roughly 6 picas to the inch. I'd love to see another unit option that allows for this (go with digital picas if you prefer to keep it a straight 72 points / inch). This would add an important underpinning for your upcoming Publisher product, where I guarantee many of us who work with type will demand it. Thanks, and I'm going to go back and play with these new toys now… -- Matt