MikeTO

While waiting for somebody more knowledgeable to answer your question you could try changing the default application to open that image format type from Affinity Photo to Photoshop or vice versa, just reverse whatever it is.

SVG was created for websites, not for printing. EPS is the analogous printing format. SVG and EPS are vector formats. Vector images can be scaled without loss of quality because they are stored as X/Y coordinates, lines, and curves. TIFF, PNG, and JPG are raster formats, stored as a series of pixels. They need to be created at the appropriate size for printing or you'll see jaggy edges (too low resolution) or created huge files for no purpose (too high of resolution). PDF is a document format, intended for an entire page and not a graphic embedded into a page. A PDF can include raster and vector graphics. Publisher can import all of these but importing hundreds of tiny PDF lines of music into a Publisher document adds a great deal of overhead because each of those lines of music is a complete document. That's why we previously recommended you use a different format. EPS is actually the ideal format for what you're doing (music scores can easily be defined as lines and curves) but as you were having technical issues I recommended TIFF because it's the simplest format and will give you great quality as long as you pick the right resolution for printing - your printer can advise the resolution to use. One reason to avoid EPS is that like PDF it can include fonts. If you have text in your music scores with you almost certainly do, using TIFF will convert that text to pixels. But if you export the music as EPS the fonts may be embedded. Publisher should be able to handle importing 500 music score EPS files each with embedded fonts, after all, they're the same fonts over and over again, but why stress out the application if you're already having problems? Linked TIFF files will just work without issues.

I've come across an odd text wrapping issue and I've duplicated it in both 1.9.3 and the latest beta. I've made a simple test document to demonstrate. I can easily work around this issue manually and most people won't encounter it so I think it's a low priority bug. The inline object at the top of the right column should be at the top of the column, below the static object which has text wrap on. Instead its position varies depending on its own height which obviously shouldn't be the case. A couple of clues: If I delete the static object above (which has text wrap enabled) and add more text to the left column the issue does not occur - the issue is related to the interaction of the wrapped object and inline image below. The problem occurs only when there is a previous column or text frame - the issue has something to do with text flow from column to column or frame to frame. This is evidenced by the simple workaround for the issue. If I insert a column break immediately before the object the problem disappears. Baseline grid is on but turning it off has no effect. Screen Recording 2021-07-26 at 9.01.22 AM.mov Wrapping Test.afpub

You need to increase Paragraph > Spacing > Leading.

I agree with Walt, you'll need to use them as intended and trying to rename them will only bring you grief. The notes I provided on what each style is for is probably the best available help documentation. In fact, it would be helpful if a cleaned-up version of those notes were added to the help system as it lacks documentation on the generated styles.

Click View > Studio > View Right Studio (at the bottom).

If you think there are too many styles then it's a good thing they didn't add one more layer of base styles to simplify formatting of multiple TOCs. The ultimate TOC style implementation would have included a base TOC style on which TOC 1: Entry, TOC 2: Entry, etc are based. This would have let you change the formatting of all of your TOCs at once. I have no quibble with the number of styles - this is what's needed to give us full control over the formatting of multiple TOCs and the single Index and I really want the full control. And it only generates the styles your TOC or index needs. I do wish the names were more consistent and of course they need to fix the bug with renaming the generated styles. And the index styles should be hidden in the Text Styles panel when the insertion point isn't in the index, just like the TOC styles are. Serif took a very different approach than Adobe when it comes to creating TOC and Index styles. Adobe lets you create your own styles while Affinity automatically generates the styles for you as a starting point. If you're familiar with InDesign and created your styles first then this will be frustrating but for most people Serif's automatic approach is better. However, the style names may not be what you expect, are confusing if Show Hierarchical is off, and aren't documented so even an experienced user has to play around with the styles to learn how they work. Once you understand it then the style set up is a breeze. Perhaps a future version of AfPub could retain the automatically-generated styles which is nicer than InDesign but add a dialog to swap out those styles for your own if you prefer that approach. Then you'd have the best of both worlds. I'm hoping for support for multiple indices someday, although that will bring more text style complexity.

No, TOC 1: Entry has to be a paragraph if you want to control things like leading. Page number only needs to be a character style. I believe this is the full list of styles generated by AfPub for Tables of Contents (where # is the number of the TOC, e.g. 1 in the first TOC inserted) para style: TOC #: Entry - base style, not directly applied to anything. para style: TOC #: Heading 1, based on TOC #: Entry - applied to level 1 headings. para style: TOC #: Heading 2, based on TOC #: Entry - applied to level 2 headings. Etc. char style: TOC #: Number - base style, not directly applied to anything. char style: TOC #: Heading 1 Number, based on TOC #: Number - applied to level 1 page numbers. char style: TOC #: Heading 2 Number, based on TOC #: Number - applied to level 1 page numbers. Etc. Where as for Indices, AfPub generates: para style: Index - base style, not directly applied to anything. para style: Index Section Heading, based on Index - used for the optional A, B, C... headings. para style: Index Entry, based on Index - another base style, not directly applied to anything. para style: Index Entry 1, based on Index Entry - applied to main topic entries. para style: Index Entry 2, based on Index Entry - applied to sub topics. char style: Index Entry Page Number - applied to all page numbers, not based on anything. char style: Index Cross-reference - applied to the "See" or "See also" text. char style: Index Cross-referenced Topic - applied to the See/See Also topic referred to. This all makes sense but there are inconsistencies: Why do TOC styles get segregated into a separate list of styles available only when you need them while the more numerous Index styles clutter up your main text style list? Why does TOC #: Entry have a colon while Index Entry does not? (IMO it's better without a colon) Why does Index Entry 1 include the word Entry while TOC #: Heading 1 does not? (IMO, the latter should be TOC #: Entry 1 for consistency) Why does Index Entry Page Number include the word Page while TOC #: Heading 1 Number does not? (IMO, shorter is better along Page does add clarity)

It might be easier if you just uploaded this test document. You can achieve the spacing you want when Body is followed by Heading 1 by adjusting the 'space before' value for Heading 1. You could also adjust the 'space after' setting for Body but that would have other impacts. BTW, if you find the behaviour of the Text Styles panel confusing, you might consider clicking the hamburger menu icon in the upper right of the Text Styles panel and choosing Sort By Type. That will separate the paragraph and character styles but not change any functionality. I prefer to sort by type because I use the paragraph styles constantly and the character styles only for limited overrides. You might also expand the Current Formatting box at the top of the Text Styles panel by clicking the > symbol to its left. Doing this will provide more room for information.

You have two TOC 1:Entry styles because you tried to rename this style. AfPub should not allow you to edit this name because it's not editable. If you edit it (which as you noted doesn't appear changed in the style panel but does when you re-edit it) and then update the TOC, you will now have a duplicate style. Long story short, don't edit TOC style names, it doesn't work and it's pointless. The same could be true for Index styles. All TOC styles have hyperlink as a style override for PDF export. The same is true for Index page numbers, they automatically have a hyperlink style override. Just ignore this, it does no harm. FYI, there is one big difference between TOC and Index styles - adding an index will add the index styles to the main list of text styles in your document. Adding a TOC is a bit nicer, the TOC styles don't appear in the main list of text styles and appear in the Text Styles panel only when you're editing the TOC. This is great because you can insert multiple TOCs, each with its own styles, and it would be very annoying to have so many styles in your main list of text styles. Maybe the same will be done for Index styles someday if support is added for multiple indices.

FYI. The Index styles work quite well. You have to let AfPub generate its own styles but then you can edit them as required. My index is properly formatted with the exception of the style override bug (the ability to have the page number for one entry formatted differently). So you can't currently do this: Doe, John 28, 171, 189 But other than that the index styles work fine.

Assuming your text frames were created on master pages, view the list of master pages in the pages panel, double click the relevant one(s), and resize the text frames there.

I banged on this for an hour and it seems solid to me. I'd be happy to switch to it from 1.9.3.

Here's another example but this one presents in an interesting manner. If AfPub is started in dark mode, inserting an index mark is not cut off even if you switch to light mode in the same session. But if you start AfPub mode in light mode, inserting an index mark will be cut off even if you switch to dark mode. There's something different about starting up in light mode than in dark mode.

I duplicated the problem, too. Strange, it only happens with tab stops in a style and not as an individual paragraph attribute even though it's the same dialog. [Edit: the problem is in 1.9.3, too.]

Preflight is great, I love it. I have one small feature request. It would be great if Preflight could catch ordinals that aren't superscripted, e.g., 1st, 2nd, 3rd, 4th. This is easy enough to do manually so it's not a big deal but it would be a nice convenience if it was easy to implement. Thanks!

If you'e already created the master pages, simply apply them to all of the pages. There is no need to fix each page manually.

I don't believe so. I'm using two approaches to captions in a book I'm working on. Most images are inline with text above and below. I simply have the caption follow the image for those cases. Other images span two columns and since there isn't a span columns feature I have to place those manually and wrap the text around them. To ensure the text flows around the photo and the caption, I group the caption text frame with the photo and wrap text around the group.

First make a backup copy. Then try installing the latest beta and seeing if the copy will open with it. You shouldn't do any work with the beta because the file format may change but if it opens with the beta at least you know the document is secure and should open in the next production release. The beta actually prompts you if you want to make a backup copy but having labeled backups is always a good idea.

It works fine for me but it works differently from Photoshop if that's what you're used to. Instead of selecting an area and then choosing Crop like in Photoshop you would select the Crop tool, move the selection handles to the desired cropping area, and then click Apply in the Context bar (or press Return). If you don't have the Context Bar open you can still press Return to apply the cropping area.

Whatever file format those photos are, perhaps JPG, is now associated with Affinity. This just means that when you double click the files they will open in Affinity. There is no change to the files though so you can send them to your relatives and for them they will open in whatever program is associated with JPG files. In other words, don't worry about it, this is the way it's supposed to work.

I absolutely love baseline grid. 🙂 It's probably due to my minor OCD.

These are incredibly minor display issues in light mode which could be saved for a rainy day when you're bored. 🙂 The Current Formatting control at the top of the Text Styles panel has a border style applied to the inside of the control which cuts off the descenders of the text. There is no border in dark mode so it looks fine there. The icons in Picture Frame Properties should either have a border applied or be modified so that their background grey colour doesn't almost exactly match light mode's default grey colour. They just disappear into the background of the popup.

I think Invision Community which powers this forum is having some challenges with Safari at least on Catalina. Here's a support thread.

You'll want to edit the styles and set Paragraph > Tab Stops as follows: Right 0 in from right. To get the dots click the ellipsis next to the tab direction and select (.) When you're done it should look like this: