garrettm30

I will report my specific observations in the beta forum as needed, but here I will speak more generally. First, I absolutely must say, “Thank You” to the Serif team. IDML conversion is surely going to get better than it is in its very first public beta, but this version right here has already satisfied what I need out of IDML import. By way of peremptory tempering of expectations, I think a word of caution of what we can reasonably expect of such an import might be helpful. If you expect this to provide a sort of interchange format, to freely move between InDesign and Publisher, you would be mistaken, and not just because there is currently no IDML export. Similarly, if you want to just quickly open an old IDML file and print some fresh copies (expecting it to look the same or even good enough), then you are probably mistaken there as well. People who have used Markzware may be able to provide some context. Markzware is a company that specializes in making conversions between a few major formats, notably between InDesign and Quark, and at a price much higher than the whole Affinity suite itself. I have experience with Markzware going from older Quark files to InDesign. It is good enough to let me open old files and copy out the assets into a fresh document. In my opinion, it is not good enough to convert and pick up where the previous designer left off from the same file. That is not to disparage Markzware; it is just the nature of layout format conversion. So rather than an interchange format, if you consider IDML import in Publisher as a means to get to the assets in an old InDesign file so you can copy them and work them into a fresh document, then I think this new capability is great. If you want quick conversion of an old document with maybe a fix of a typo that got missed the first time around, you would generally get better results by letting Publisher convert from PDF. Back when we were using Quark, PDFs were still new, and proprietary to Adobe. Quark could not even natively save as PDF without some sort of plugin. These days, I try to save everything with a PDF that is print-ready and a separate PDF that is made for viewing (such as to be put online). I operate with the assumption that the next time I might need to reuse a file, the original app may no longer be available to me.

When the language (spelling attribute of the characters) is set to French, and the Publisher preference "Change straight quotes to typographic quotes" is checked, the straight apostrophe gets converted to a space plus a curly apostrophe. This extra space should not be there. For example, try to type the common French word "c'est" under those conditions, and it gets changed to "c ’est." This occurs in Publisher beta 1.8.0.499 on macOS 10.13.6 (I am testing on my much older system at home; whereas I am usually report from my much newer work iMac). This appears to be a regression, as the problem does not occur in 1.7.3 on the same system.

I have discovered a case where I cannot "learn spelling." In the screenshot below, I tried to right-click on the name Malchus and select "Learn Spelling." But when I did that, the word would not be added to the French spelling dictionary. The undo history also shows Learn word: "" It appears to be related to text in a text frame that comes from a master page. When I tried to create a simple file with just that one paragraph to include with this post, I discovered that the word could be learned if I just made a simple text frame on the page and pasted it into that frame. However, when I created a text frame on a master page, and then pasted that text on the page that was based on the master, it could not learn the word. I have included a small file with these conditions. To test, try to "learn" the spelling of Malchus. I tested on both the stable version and beta 458 on macOS 10.14.6. learn_spelling_test.afpub

There are quite a few places in the interface where attributes with mixed values display the value of the first character only rather than indicating it is mixed. You may be glad to know that multiple bug reports to fix these issues have recently been logged, and the 1.8 beta made the first step in correcting that. Some of the discussion was happening here:

I agree that your manual look has better spacing. One thing I noticed is that you twice allowed three consecutive lines to end with hyphenation, where the software (I am not sure which you used) may have been configured to only allow two, which I think might be the default in some cases.

That is “safe” only if all the styles you might use in the document are already in use, which I find to be rarely true at the stage where I am importing text from another document. In that case, I am rather at the beginning of the process than the end. It is not that Publisher can’t achieve the same result as InDesign with a different means in this case, it’s just that the currently available means are cumbersome by comparison to what we who are coming from InDesign are used to doing. The more styles one has to import, the more “cumbersome” tends rather toward “tedious.” In my view, there are two design differences between the two apps that result in Publisher’s approach being slower: 1. When importing a style from the source document where a style of the name in the target document already exists, Indesign makes text with that style take on the properties of the style of the same name in the target document, whereas Publisher copies the old style as an additional style into the target document. I find InDesign’s approach much more sensible, because if it is “Body Text” or “Heading 1” in the original document, it is quite likely that the text is still body text and top level heading even in the new document. Usually I would make sure the naming in the old document matches my new document before import so that styles will be adapted to the new with very little effort. 2. The other matter is what this thread is about (though it would be needed far less often, in my uses anyway, if the first difference were addressed). Whether or not Publisher’s find/replace interface is harder to use, the option InDesign provides truly is faster. The following dialog pops up any time you delete a style that is in use: Regarding the find and replace function in Publisher, I too have felt that it is much slower to use, but I haven’t yet understood why. The biggest difference to me is that one cannot save searches for reuse later, so I am constantly configuring the same searches that in InDesign I configure once and save for quick reuse later. Besides that major difference, I am still trying to decide whether it is merely a different layout of options that I have yet to become fully accustomed to or whether there is some inherent issue that makes it slightly more difficult to navigate.

Note that once a single frame was scaled in this way, duplicating it will mean that the copied frame will inherit the same scaling.

I didn't realize scaling an object in that way was "non-destructive." That's not quite the word I need when talking about vector objects, but I mean that the scaled object apparently always contained a record that it is scaled, whereas I thought it was just resized and the new values replace its past values. This indeed gives rise to the question why the scaling factor is not exposed in the UI.

In fact, this is easy to do with a fresh document in Publisher 1.7.3 when setting up a new document: text_size_in_frames_2.mov Is resizing text frames supposed to behave this way?

Thank you for the file. I see what you mean. I have made a quick video to illustrate. Off the top of my head, I cannot explain why it is behaving this way. text_size_in_frames.mov

Maybe it is worth noting that not only in 1.8 beta, but there is also improvement in the release versions that have come out since the thread was started last December. If I remember the recent history, when this thread was started, all "linked" resources were actually embedded. That is not the case anymore, but certain types still are embedded in the current 1.7.3. To be specific, I think it is Affinity documents and PDFs. Raster graphics are not. Someone correct me if have the filetypes wrong, because I haven't much paid attention to this.

Yes, I agree:

It appears you were not in fullscreen mode at the time you made the screenshot. Maybe you had just come out? Also, do you use the monochrome icons? I ask because it appears the various controls are grayed out. Even the window controls (close window, minimize, fullscreen) are grayed out. Do you remember having some kind of modal window open at the time?

I saw it just a couple days ago in Publisher beta 1.8.0.499. I thought to report it, but when I restarted Publisher, the search box was back. Thus far I can't figure out what steps to get it in this state. I have the vague idea it is related to changing to or from full screen mode, but I can't replicate it when I try to play with it. My theory is that the search bar is cut off on display because of an incomplete change in the state of full screen mode. I have seen issues with the hidden menu not appearing as it should with the full screen mode of other apps as well.

And in case you want to comment on the H&J violation feature request, this is the thread yesterday it was requested: For my part, I can imagine some kind of highlighting interface (set up like the snapping interface is now) that would offer options to highlight all kinds of different things. For me, H&J Violations, style overrides, and specifically kerning/tracking overrides are the three that I would use most often. That would be the kind of whizz-bang new feature that could motivate me to immediately purchase version 2 whenever it might eventually come out. …Who am I kidding? Despite my various requests, I am in general becoming such a fan of the Affinity line that I am sure I will purchase it day one regardless.

This is a very novel idea. I do often clean up justified text, so I encourage anything that either makes the default results better or that helps us with manual tweaks, such as the suggestion yesterday about highlighting justification violations. Yours is one of those ideas. I understand what you're saying, and I do think it is worth considering. I like the idea in principle, but I think I would have to spend some time using it to see if it is helpful in practice. If Serif implemented it, it would be unique for sure. A couple points come to mind. Although your mockup shows it together with left-aligned text, I would feel the greatest need for it with justified text, but then the aligned right edge would somewhat diminish its value. Also, you have shown it with unhyphenated lorum ipsum, but long words could still offer short hyphenation options. Anyway, thank you for thinking outside the box.

One further tip along these lines: if you zoom by scrolling (opt-scroll on my configuration), the center of the zoom is wherever the pointer is.

It doesn't look like I have commented on this yet (I can't keep up with even my own posts). So let me say that a preflight panel of some sort would be a nice feature. I can envision it as the kind of thing that would be a version 2 addition.

About the fonts, I think we are headed that way eventually. See especially Patrick's post on collecting fonts: Notice: the current new feature is "a start along this path." I take this to mean that they have heard the requests for packaging resources, they have started work on it, and in the new beta they are ready to share their progress so far, with evidently more planned. The new beta is just the first step in that direction, and I think it was good of them to share what they've done so far rather than wait until the whole thing is complete, especially as it seems they are not going to be able to complete their vision for this feature by 1.8 release.

Besides which, for the sake of plain old accidental clicks, I like confirmation on operations that are not easily undone. After more than 30 years using a mouse, I find I still miss my target on occasion.

I probably should have written it more fully as "the format modal window." It is the window we have been talking about, where we pick the format to search for. It is a modal window because it takes over the app until we close it.

I think this is a matter of preference, but I would prefer the styles to be in the format modal like the other formatting options.

I have used it some in InDesign, but I would probably use it a lot more in Publisher because it requires a lot more manual tweaking to get good justification, and that would help visualize the issues better.

Then that may well be the problem. In another thread, a user was getting crashes with only 18GB left, whereas according to the developer his particular file would need 25GB of free space. That is a different document with different issues, of course, but as you may be approaching the limit, there could be issues with disk thrashing.

This is an interesting discussion, and I agree that something could be done better than it is. Of course, one can generally achieve what is needed via character styles**, but I think there is room for improvement. In Publisher as it is today, if I did not like the size or position of a superscript, I would create a character style that changes size and/or baseline position, and then I would apply this character style by a find/replace operation. Besides the slight inconvenience to manually apply the style (whether find/replace or otherwise), there is this further disadvantage. Imagine a run of text that already needs a character style (let’s say “emphasis”), and that text contains a superscript. Now in addition to your “superscript” character style, you need an “empasis+superscript” style that combines emphasis with the desired look of the superscript. This is not the end of the world, mind you, but I do think it invites improvement. InDesign allows setting a global superscript size and position in the document preferences, which is probably where Petar is coming from. I agree with fde101 that it really doesn’t exactly belong in preferences, and I agree with Garry’s point that the disadvantage is the “dangerous” assumption that “every font would look okay with the same settings.” I believe that InDesign is currently superior to Publisher in this one respect, because it does offer the global preference in addition to the character style method that one must use in Publisher, but I think there is room to 1-up InDesign. Before going on, I should point out that preferences in InDesign are different than preferences in Affinty. In Affinity, they function like preferences usually do in other apps, in that they are application settings. In InDesign, they are generally document-level settings. That approach has its merits, but I think on the whole I am not an advocate of that approach. It does mean that in this case, setting a global superscript size would be true for the whole document (not the whole app), and it is saved as part of a document. So Garry’s other “dangerous assumption,” namely “that every document that was typeset with previous settings would still look okay when viewed/edited with the new settings,” while true if added to Publisher’s preferences, are not true in InDesign, because those preferences travel with the document. Document-level preferences aside, InDesign does assume a document-wide setting is sufficient, but what about multiple fonts in the same document? Can we assume that one setting would fit all scenarios in a single document? Often, yes, but in those cases where it doesn’t work that way, then we’re back to the same character style workaround. It is as fde101 has said: this is inherently a character style attribute. I think we can come up with better. Here’s my proposal. I do think it should be a character style attribute (also in paragraph styles of course). But I do not mean to create a special character style just for superscripts. Rather, I think the InDesign-style settings would go well in the Position & Transform portion of the Publisher character styles, like this mockup below. Then one would not need a separate style just for superscripts, but rather it would be coherent with the rest of the text. **Except horizontal offset. I have personally never needed something like it; I wonder how often others might need it. Size and vertical offset—those I have used, and not infrequently.