garrettm30

Hyphenation is surely part of the line-width calculation that Publisher contends with, and it is probably involved here. But turning minimum score to 2 all but turns off hyphenation. In the actual document of 8 pages, a setting of 2 results in exactly one hyphen through the whole document and tons of unsightly gaps that could have been solved by hyphenation. Minimum score of 0 is a legitimate setting and in itself not the cause of lines overlapping. Turning off hyphenation does cause the problem to not manifest in this case, but so does turning off drop caps, or turning off the numbered list. I suspect it is somewhere in the combination of those things. As I said, I have already worked around the issue for this document; I am just reporting of the issue to Serif, and Dan C was right to log it.

I recently encountered an issue in one of our documents that made use of a paragraph style that combined drop caps and numbered list. It worked in most occasions, but it appeared Publisher had some issue calculating when to break for the next line if the line was at a certain length. I was able to work around the issue for our publication, but I have copied one of the problem paragraphs and reduced a lot of the formatting choices to narrow it down. Attached is a sample document with this problem paragraph in cut-down form pasted multiple times. For comparison, here is what I expected the cut-down example to look like: And below is a brief video of what I am actually seeing. In the video, I first try changing the text-frame dimension, and then I try changing the horizontal character scaling. In both cases, I can find combinations that work and do not work. Sometimes when it doesn’t work, it is just a wrong indent, while other times, we have a collision of two lines in the same space. dropcap numbers oddity.mp4 Here is the file from the video: drop cap numbered list.afpub Tested in Publisher 2.1.1 on macOS 13.4. I have also tested in beta 2.2.0 build 1931 with the same results.

This is a nice feature also. As I consider this together with the object creation with data entry, I see that you are on the way to creating something like an on-demand version of features in the Transform studio without needing to keep the studio open. I would be interested in that to free up some space, because otherwise I personally have the Transform and History studios with tabs sharing the same space on the sidebar. But it is lacking a couple of data points (absolute position, width/height sizes) to fully achieve that. Another way to think about it is that it is now an interface for the power duplicate feature. But here too, it can’t handle everything that power duplicate can, such as resize and (as was mentioned above) rotate. It may not make sense to take it all the way for full feature duplication of transform and power duplicate, but maybe some of these things could make sense to add, perhaps even with an expansion triangle for more options.

Unless I missed something, what I see in your video is the behavior I would expect. The shape is supposed to move around based on which origin point is selected. The absolute X & Y position of your click should stay fixed, but which point on the object that the absolute position relates to is what you are selecting. For general feedback of the feature, I would add an X and Y field, prefilled with the clicked position if in canvas (i.e., the position that is used currently in this beta). I would suppose the main advantage to numeric entry would be precision versus the imprecise nature of clicking and dragging, but the same would be true about the position of the initial click (though snapping does really help). As an added benefit, this numeric entry makes automation through solutions such as Keyboard Maestro more achievable.

That is basically my point, and you have illustrated it from a different perspective. Thank you. Perhaps it is not about custom text variables as they are currently implemented, but as we are discussing feedback about the current implementation, I do think it is important here. I would like to point out that what we are talking about are indeed text variables, as many of the people who are coming from InDesign who are making the request for text variables have this in mind. To illustrate, here is a picture of InDesign’s text variable interface as I used it for running headers in that Bible project several years ago. I also do not think InDesign was inaccurate in using the term “text variable,” as it indeed is variable text that will be inserted at a given location. When InDesign folks are going to see that “custom text variables” are a new feature of Publisher 2.2, they may end up disappointed when they see it is more limited than they were expecting. Having said all of that, I recognize and can appreciate that what we are looking at in this Publisher beta may not be Serif’s end goal for this feature. I only mean to leave feedback about the current form. However, as far as functionality, it seems that Publisher has basically already got what it needs; it is just the interface is a bit clunky here.

A proof of concept is all I needed. Thank you so much for explaining. Now I understand how to have multiple instances of a “running header.” With that improved understanding thanks to Old Bruce, back to my feedback… So for the most part, it seems like the functionality for multiple dynamic variables is already there, with the exception that they cannot be named or edited with in the Fields panel in any way other than individually. The way it is presented seems to be a misfit. For one thing, the name “running header” seems off, because although very often they would be used in that way, apparently it can be used anywhere anytime a dynamic variable based on a text style is desired. But what led most to my confusion is that the Running Header section in the fields behaves differently than (I think) all of the other fields—well, date also. For all the other fields, they will always behave in a consistent way across the document. For editable fields, such as Author, if you edit the field, it edits it everywhere in the document at once, but not so with Running Headers and Date. I made a video to illustrate the difference, but I changed my mind thinking no one would want to watch it. The gist is that I think Running Headers and Date should work globally like all the other fields, so that it works consistently and therefore works in an expected way, but also gives a convenient way to edit those globally. I would move both “Running Header” and date down to custom section. Currently the new custom variables/fields of a text type, just as Author, Comments, etc. I suggest making possible other types of custom variables, such as the “Running Header” type based on style (it should probably be renamed), date and time, and probably there could be others, such as sequential counter, whatever. To illustrate, let’s take the date field. Let’s say I use the date many times throughout the document, but as time goes on, I decide I wanted the date syntax done slightly differently. If it were like the other fields, I could just change its property once and it would update everywhere. But with date, I have to select each instance and then make the changes one by one. It would be better if I could have defined one date custom variable set up the way I wanted, then I could change all of them later if I wanted to. Or maybe I have two: longDate and shortDate each as custom variables. A slight variation to this idea is to leave Running Header and Date where they are rather than move them to custom, but make it still behave globally. And so that users can add more than one, add an option to add additional fields of the same type, maybe Date 2, Date 3, etc. This option would also solve the double problem of making this discoverable and providing the same convenient global editing that the other fields already have. I hope this makes sense—maybe I should have just posted the video. Anyway, there may be some better ideas, but I think the current behavior of the Fields studio where two of the fields work in a completely different way than all the others invites rethinking.

That’s good to know. Maybe then it is nothing more than a simple bug. This is what I see on Mac: And it is not just the look: indeed the scope cannot be changed in that state.

I did not know you could have more than one instance of the “Running Header” defined each to a different text style. The Fields studio leaves the impression that the Running Header can be configured to only one text style. Do you happen to still have that sample document so you could share it and I could play with it a bit? I don’t understand how to do it, or how to edit the running header parametiers field if there is more than one.

Maybe this feature is yet to be expanded after the basic functionality is sorted out, but I had expected that the custom variables would have basically the same dynamic nature as the field called “Running Headers.” Sometimes a book might need more than one dynamic variable, and I am not sure this is possible even in the new beta. Sometimes even actual running headers need more than one dynamic variable. For example, for in the Bible that I did the layout for a few years ago in InDesign, the running headers had to use two different dynamic variables based on text styles: a book name and a verse-chapter reference (a very common feature in most Bibles, similar to the headers in a dictionary). As I understand it, it still does not seem that this is possible in Publisher. I’m in no hurry, but when the time is right, I suggest you consider allowing custom variables to be defined with the same or similar functionality as the existing “Running Header” field type. Of course, this would not be to exclude the possibility of variables with a fixed value as in the current beta. Perhaps the “Custom field properties” is so named using the plural because it is in anticipation of additional features for custom fields even though currently the only property there is the field name.

This is a welcome change. One minor point: is there any reason why one can’t select the scope before search parameters are entered? If the search field is empty, and no find by format is select, then the scope drop down is disabled, retaining its previous selection. It just seems arbitrary, because scope, while a very welcome addition, is also a common point of user error where we forget to set it to the correct scope for a given search. So imagine this scenario that sounds like just the kind of thing I would do: Begin a new search. Notice that scope is still left at a previous setting that is not fitting for the current task. Normally I would wish to change it when I notice it, but I cannot do so with an empty search string. So, I start working on the search string. Often it is regex, so my mind is fully occupied in working out the desired regex, maybe even hopping back and forth with some tool such as my beloved regex101.com. My mind has moved away from the question of scope, as I have forgotten to come back and change scope. I run the find (and maybe replace), and the results weren’t what I expected. It is not an end-of-the-world scenario, because often I would notice, fix scope, and run again. Occasionally I might miss it, with consequences showing up only later when my scope was larger than I thought, or things not fixed that I thought I had fixed because the scope was narrower than I intended. The point is that I would like to be able to set scope as soon as it crosses my mind, because I cannot be sure that it will cross my mind again until it is too late.

I too have tested a couple of documents where the nonbreaking hyphens do not work in the release and do work (i.e., is fixed) in the beta.

I hope I don’t sidetrack this thread, as it is supposed to relate to scripting. But just to answer you, I am in fact a WordPress developer for our organization; I could make a plugin for this if it were needed, but in this case it is not the WordPress side but the original source text that I would need. I can easily get the text by copying, but the text loses a lot once it leaves Publisher. Most of the formatting I would not need, but I would need what effectively amounts to semantic markup. This could be accomplished on Publisher’s side, since within Publisher the text still has text style information that I can map to markup. Note I am not really asking for Serif to implement anything regarding this example. I am simply responding to the request for ideas about how we might use scripting.

I would be afraid of piling on to an already quite long thread, but since you asked! … My first thought would be the ability to automate tedious series of find and replace. Presently, I use the automation tool Keyboard Maestro (which, by the way, I learned about a few years ago after seeing it mentioned by others on this forum) to run through a few tasks for me on a regular basis: A set of 15 typographical replacements that are used for most of our publications. I have Keyboard Maestro offer me the choice of which replacements to make on a given run: Keyboard Maestro then operates Publisher to apply a set of find and replace strings (mostly regex) that I have configured. I have Keyboard Maestro export to PDF our various publications in the formats that they require with the final print files. Different kinds of publications require different settings, and in most cases we export for both a PDF intended for web and a print-ready file imposed for our own equipment. Some of these documents can have PDFs made directly from the Publisher file, while some need to be imposed in a different way. In the latter case, I have Publisher templates prepared wherein I can (or Keyboard Maestro) place the original document to create a ready-made imposed form. In other cases, such as booklets, I export the PDF pages from Publisher and then process the files further in Create Booklet 2. I have configured Keyboard Maestro to automate all of that process, so that I pick a Publisher file and select one of my preconfigured formats, and then I let go of the controls and let Keyboard Maestro operate the computer for me until I have PDF files properly named and saved in their proper locations. Those are two typical examples. I am glad for Keyboard Maestro, but sometimes you have to get creative to think about how to get it to operate a user interface designed for humans. Things like menu items are foolproof, but things requiring clicks and visual interpreting a UI are trickier, and the setup can be very precarious and easily broken. The ability to add scripting in Affinity could really help in these cases, if I understand correctly. As for the Find/Replace routine, it might be possible that I could do it entirely in a script, although I do not know whether there will be (and here is perhaps my first actual suggestion) an interface for the script to pause to get user input, such as for configuration of parameters, like in my screenshot above. But even if not, I can have each find/replace pair to be saved as a script that Keyboard Maestro would be able to access far easier via menu item versus trying to operate the FaR Studio that was designed for a human. I don’t know whether you currently have in mind for scripting only to be from within Affinity, or whether there will be an API that 3rd-party apps could access. I know I have seen some requests about that. For me, scripting within Publisher will be great already, and access outside of the app would be even better. A couple other ideas that scripting might be useful for in my needs: I would like to make more efficient the process of taking text from a Publisher document to be put online in WordPress. I can imagine I might be able to make a script that could copy a text thread as raw text but with markup, where I might have carefully matched up text styles with HTML markup: for example, the text of a paragraph with the paragraph style named “Subheading” might be wrapped in <h2> tags in the final copied text. And then I could just paste the resulting text into the HTML editor in WordPress, rather than manually going through and reapply the various formatting elements that didn’t come automatically in the current method. And if the script can pause for user input, I can pair styles at runtime rather than carefully set up my style names. Antidote integration, which a few of us have been interested in, might well be possible through this. It is a grammar checker (among other French and English language resources), and really its integration needs are pretty simple: it just needs to be able to receive text and send it back with edits. The trick will be to do so with formatting intact. Once the feature is available, I’m sure more ideas will start popping up of how I could make life easier in various aspects of using Publisher. I am very excited about it.

Haha! Inflation is to be seen everywhere these days, even in our idiomatic expressions. By the way, welcome to the forums, Vladstudio. (In case it is not clear, my joke above only relates to the typical expression “my two cents,” not to any criticism on the value of the feedback.)

I found this problem as well and prepared some files to start a thread, but having searched and found this thread, there is no need to start a separate thread. But one element I can add to the discussion is that this problem is new with Publisher 2.1. I restored a copy of 2.0.4 via Time Machine to test. Here is a sample file non-breaking_hyphen.afpub when viewed in 2.0.4: The same file when viewed in 2.1.0: This is not the typical missing glyph substitution where a fallback font is used, but rather this happens at the Unicode level within the same font. The decomposition mapping for U+2011 is defined as: I don’t want to pretend expertise in fonts and Unicode here, so someone else who does know these things can confirm or correct, but my understanding is that it means that unless U+2011 is explicitly defined with its own character form, it should use the form defined in U+2010 with the noBreak value applied. I tried it with Apple Pages and Microsoft Word. In both cases, the non-breaking hyphen using the same font (here Arial) does show a hyphen and does retain its non-breaking quality. As far as I am able to determine, this is standard behavior for Unicode.