sfriedberg

@vdamjanovskiIt sounds like you are not using Sections, and have assigned different master pages to your chapter heading pages. Try breaking your text into Sections that match your chapters. Each Section can grow or shrink in number of pages without upsetting the start of the following Section (or end of previous Section).

I don't know about this problem specifically, but tables in AffPub have an awful lot of "weird" behavior regarding column and row sizing and text wrapping and/or insets within cells, and it does often take the form of "inexplicable widths/heights" which cannot be quickly fixed by straightforward user GUI interaction. I have had to give more than one table the "burn it with fire" treatment to reset its layout, and on a couple of occasions I have had to abandon the corrupted table and simply construct a new one. It would not surprise me if this is indeed a bug in table behavior. If we can see a copy of the affected document (the document itself, not a screenshot of the document, please), we might be able to assist more specifically.

@keithrtEven if you edit the front curve, you will still have to realign the triangles to the new curve position. Grouping does not auto-deform all the members of a group in response to modifying one member. Affinity doesn't currently have a "free deformation" or "mesh warp" for vector graphics. If it did, you could do modest tweaks to the entire group, with all members of the group deforming consistently. You'd probably want to update/replace the fixed symbols like triangles after larger deformations to restore their original shapes. We will probably never get (I'd love to be wrong) a feature where certain members of a group translate and rotate, but do not individually deform, in response to deformation of the group.

If the title text frame holds only the title, and it is to appear to the left or right of the two main frames, then you can pin the title text frame "floating" outside the text frame in which the anchor is pinned.

I'm not sure that 100% communication is happening here. Initial View settings are a feature of PDF files. Simply exporting as spreads rather than pages will not impact the Full Screen option of the PDF Initial View settings. Have a look at https://helpx.adobe.com/acrobat/using/setting-pdfs-presentation.html or https://kbpdfstudio.qoppa.com/set-a-document-to-open-in-full-screen-mode/. PDF readers also have view settings. However, the Initial View settings contained within a PDF file are intended to give a reader a clue that its default view settings should be overridden for the particular PDF file. The Full Screen option is often used in kiosk applications, and it's clear that the OP's client and/or publisher requires the Full Screen option to be set. Therefore individual user preferences do not apply as the client/publisher is establishing a consistent user experience across documents from many sources.

Since the unit numbers are all in a group, open the group and block-select them. (On Windows, select the first one in the group, then hold down the Shift key and select the last one in the group.) Change the font size on the context toolbar, under the main app menubar. Unless you were incredibly clever about how you set their horizontal/vertical centering, you will have to reposition all of the unit numbers after you resize them. In which case, you only save a small amount of time by resizing them all at once.

This is actually a fairly common thing. Let's say you have paragraph styles Heading1 and Heading2. In systems that support it (Affinity Publisher currently does not), you have fields like (names are made up) "FirstHeading1ContentOnCurrentPage" and "FirstHeading2ContentOnCurrentPage". You can insert those fields in headers/footers. So it's quite easy to have both a section name (e.g., "Chapter V") and a running head (e.g., "Gunboat Diplomacy", "Geopolitical Setbacks") which changes based on the content on the particular page. When used for running headers/footers, you generally want to pick up the content for the header paragraph in effect at the top of the page. So if the most recent occurrence of Heading1 was three pages previously, that's the content you will use. If page starts immediately with a Heading1, then that's the content you will use.

Here your use of "layer" feels ambiguous to me – although you point out a need to distinguish between various layer types + a need of clear terms in your recent post: "we need to be careful about terminology". I my opinion it is in fact desired + an advantage that a "layer" may be nested within a "layer". What you possible mean: there is no global layer nested in any layer (the page as kind of the main layer excepted). But this was already mentioned various times above. So actually I don't understand for what purpose you make this statement. I think this is one of our points of divergence. An object is not a layer! A group of objects is not a layer! A layer (any layer) is a container for objects and groups of objects, any number of them, including zero. This is one of the characteristics which distinguishes a layer from "a group of objects". There are other such characteristics: layers lack a transform (either position or scale). An application can support nesting of layers within layers, but this is not essential. Applications can quite as well support a single set of "top-level only" layers, where all interior nesting comes from groups of objects (which are not layers). I strongly prefer the 2nd model: No nesting of layers within layers. At all. Now, if you want to make global layers special, so they can contain local page layers and master page layers, I can live with that. Also this thought is unclear to me. Note: on every page (master or not) each item in the layers panel will be 'nested within exactly one global layer', not only master page layers or especially master page layers. – So, it appears you confuse in this statement "master page layer" with "global layer". No, I did not make any such confusion. I was referring back to @garrettm30's example with three global layers, and master page layers from one master page assigned to different global layers. The assertion I was rehearsing was that a given, specific master page layer always and everywhere belongs to a single global layer. And while I can grit my teeth and tolerate it, I really don't see the need for local page layers to be nested within (any) global layers. 1) Why do you restrict master page layers to single objects? "It refers to single objects (each of them placed on a mater page layer)" is a substantial confusion of object and layer, in my opinion. 2) On a documents page, "master page layer" had better refer to one layer of the master page, not all the layers of the master page! The master page(s) has as many layers as the user defines it to have. They are distinct layers. They better be visible and manageable as distinct entities. In the previous conversation, the various layers of a master page would be assigned to different global layers. So you can't possibly "refer to the entire master page contents". 3) As mentioned above, I was trying to capture my understanding of the discussion. Your reply has dashed any hopes I have of claiming comprehension and agreement. Are you sure? Where do you do this? – For what purpose… a.) … should exceptionally objects newly created or moved on a master page make their layers appear in the layers panel of document pages? b.)… would we need the layers panel to select an item which is an instance of a master page – instead just click-selecting the object in the layout view / the documents window? For the purpose of assigning the content to a layer, of course. If the layer is empty (on the current page), then by the green highlighted phrase, in my preferred cleaned-up UI, the layer will not be shown. In order to assign content (for the first time on the current page) to such an empty layer, I have to see that the layer exists. I have no particular desire to see master page layers editable when the user is focused on an ordinary page/spread/artboard. If the user is focused on a master page, then obviously the content is going to go into a master page layer. If the user is focused on an ordinary page/spread/artboard, content generally is not going to go into a master page layer, and I would be happy with a prohibition against it. If you (the reader, not @thomaso specifically) believe that local page layers must be nested inside global layers, then that's where local page content is going to go. If you (the reader) believe that local page layers are not nested inside global layers, then the question becomes moot because local page layers only appear on one page, by definition. And just for completeness, there must obviously be facilities for defining new layers (of all types). I don't care whether or not that can be done as part of the create new (or move existing) content functions, as it's easy to either create the destination layer before creating content, or create the layer after creating content and move the (then existing) content into the recently created, empty layer. And that is the point of "the principal exception". If there is an empty layer, which is not being shown to me because it is empty, I need to see it in the list of potential destination layers. Full stop. In response to a) 1) I was discussing creation (or moving) of ordinary content on ordinary pages, not master pages. 2) I have no difficulty accepting all master page layers including empty ones, from master pages assigned to the current page, shown in the list of layers affecting the current page, because I expect that to be a vanishingly rare and entirely transient situation. If a master page layer has no content, it might as well be removed. 3) If a layer (any layer, from any source) has content on the current page/spread, then obviously the user needs to see the content and the containing layer. 4) If a layer (any layer, from any source) does not have content on the current page/spread/artboard, (here's that green highlighted statement again), I generally don't need (or want to) know about it. But as noted in #2 above, I am not going to gas about empty master page layers. And as noted in "the principal exception", I need to see even the empty layers when creating new (or moving existing) content. In response to b) 1) Again, I don't really understand why you are narrowing in on master pages. As I stated above, if you want to show all master page layers regardless of whether they are empty, from master pages assigned to the current page/spread/artboard, in the list of layers applicable to the current page, go right ahead. And if I assign some content to a global layer which was previously empty on the current page, then I do want to see it in the page layer list (in fact, must see it). And if I remove all content on the current page/spread/artboard from a global layer, then I usually don't want to see it (the global layer), but I will grant you a dispensation for useless empty master page layers which were assigned to that global layer. But the focus of my statement was not about master pages, but ordinary pages. 2) Assuming it's possible to mouse pick the desired object (i.e., not covered in the Z stack), yes, it is just fine to select the object in the viewport instead of the layers panel. I am not sure what I might have said to suggest otherwise. Depending on the situation, it might be more convenient to select it in the layers panel, but that's entirely dependent on the situation. ----------- I intend to take a break from this discussion for some time. I will continue to read it.

You probably have the best available solution at the moment. The Affinity suite is very weak on user-defined fields or attributes, and also weak on letting you select which field or attribute of a referenced object (e.g., caption, page, ...) is expanded or substituted at the point of reference. Ideally, in some future release, Affinity will make it possible to do something that directly parallels what you can do in Scribus. But I would not hold my breath.

I could live with that, but would prefer not nesting any layers within any other layers. (Again and still, distinguishing layers from objects and groups of objects). But if you want to have a global layer entitled "Local layers" and make most/all local layers live in that global layer, well, OK. Presumably a master page layer (globaly) is nested within exactly one global layer, which constrains the ability to change Z-stacking order on a per-page/artboard basis. I guess you'd get around that by creating additional global layers above and below the global layer containing the master layer. So you'd have global layers entitled things like your example of "Top", "Middle" and "Bottom", each containing subsets of local layers. For the kind of slide set I described earlier, you'd end up with a bunch of global layers which contain a local layer on only one page, and similar things. That, unfortunately, produces the "a set of layers which is the union of all per-page layers" consequence I'd prefer to avoid. For Publisher-style documents, this would not trouble me. For Designer-style documents, it would clutter my life considerably. If it doesn't have content on the current page/artboard, I generally don't need to (or want to) know about it. The principal exception is when I am creating new (or moving existing) content and need to select from the possible layers.

Yes, this is highly desirable. It's how I am handling my current manually inserted footnotes in AffPub, and offers some leverage to fix things in the event that the automated flow/overflow calculations don't produce a pleasing effect.

@Ahura Mazda, Walt's question is key. I frequently find that I can only enter a table for editing cell contents by selecting the table in the Layers panel. None of the lefthand toolbar tools will work, for reasons I do not understand, except of course when they mysteriously start working again. Once I select the table in the Layer panel, then the table and text tools behave as expected. So we need to know if you are experiencing this problem, or a different problem.

I can confirm the behavior you are seeing. Publisher 1.10.4.1189 on Windows 10. Some tables behave better than others. In tables which misbehave, I can sometimes get close to the expected behavior by setting the No Break character property on the cell contents. I've also noticed that tables which are misbehaving often ignore, or misapply, the cell insets. So the cells are not only too small, but the contents are shifted inside the cell, frequently to the point where they run outside the bounds of the cell altogether. So I suspect there are several interacting bugs here. As a more general comment about resizing tables and table columns, I really do not care for the way columns resize proportionally. A simpler, more predictable, and easier to use UI would allow dragging the right table boundary to resize only the rightmost column, and dragging a column boundary to resize only the column to the left of the boundary, moving (not resizing) all the columns to the right (except possibly the rightmost, which might resize to keep the right table boundary fixed).

I can confirm the behavior you are seeing. Publisher 1.10.4.1189 on Windows 10. Some tables behave better than others. In tables which misbehave, I can sometimes get close to the expected behavior by setting the No Break character property on the cell contents. I've also noticed that tables which are misbehaving often ignore, or misapply, the cell insets. So the cells are not only too small, but the contents are shifted inside the cell, frequently to the point where they run outside the bounds of the cell altogether. So I suspect there are several interacting bugs here. As a more general comment about resizing tables and table columns, I really do not care for the way columns resize proportionally. A simpler, more predictable, and easier to use UI would allow dragging the right table boundary to resize only the rightmost column, and dragging a column boundary to resize only the column to the left of the boundary, moving (not resizing) all the columns to the right (except possibly the rightmost, which might resize to keep the right table boundary fixed). Maybe a forum moderator will move this to the Report a Bug in Affinity Publisher forum for the appropriate OS platform. [Added in edit: Ah, I see you already opened a thread there. I'll add my comments there, too.]

@typeglyphActually, Publisher has a fairly useful set of table and cell style controls. They aren't very well documented, and I find the UI to actually assign styles to cells a bit fiddly each time I use it "for the first time, again". But the capabilities are pretty reasonable, especially for a v1 product. You will need to open the View > Studio > Table Formats panel. This display is incredibly non-self-explanatory, but if you use the panel hamburger menu to create a new format, then right-click and edit that format, you will get to a panel which you can explore to do useful things. The triangle/diamond decorations separate header rows/columns from normal rows/columns, and you can give them distinct cell styles. I'd recommend reading this thread, as people discovered how to do some non-trivial things. And I say "discovered" because the related documentation is either lacking, hard to locate, or not very clear

I don't see the need for per-spread local layers so much in Publisher-like applications, but do use them quite heavily in Designer-like applications. This is a situation where Affinity's choice to have a common document model and file format for all apps in the suite is a double-edged sword. Any solution for Publisher needs to be a satisfactory solution for Designer. I would find the "all layers are global layers" decision to be very distressing as a user of Designer. As a user of Publisher, I probably would not notice. Yes, I mentioned this in the context of CorelDRAW, where the ability to set a mixed local/global Z stack order independently on each page is usually unnecessary, sometimes a benefit, but frequently a nuisance. If you just use the default layering, no problem. If you make any overrides to the layering, you have to manually confirm that you ended up with the correct layering on each page. The UI component that shows the mixed local/global ordering only shows one page at a time, unlike the normal layer view, which is much like Designer's layer view in artboard mode, showing local layers within each page and the master global layers within the one master page. CD does not have the concept of global layers with per-page/spread content. In CD, all layers shared across multiple pages are master page layers. All other layers are local per-page/spread layers. So this is an area where, if the flexibility is offered, then a better UI is required to manage the mixed local/global Z stack order. That's one of the reasons we are having this extended discussion, yes? As @garrettm30 points out, we need to be careful about terminology. Letting "page" stand for either page or spread, depending on document setup, I would suggest: Master pages are about replicated content. All layers of a master page are added to the effective layers of any page where the master is assigned. Content in a master page layer is replicated across all pages where the master is applied. Global layers are about consistent layer structure and management across the document. All global layers are added to the effective layers of all pages. Content in a global layer is independent for each page. Local layers are about local layer structure within a page. Local layers only appear on a single page. Content on a local layer is necessarily local to a single page. Currently, the Affinity suite supports master page layers and local layers, and allows assigning multiple masters to a given page. Are we at least in agreement on those descriptions?

Given the tenor of complaints on this forum, I am reluctant to claim anything is a must have. 😀 However, I have found it useful to have some master global (i.e., repeated content across spreads) layers above per-page content, and some global layers below the per-page content. Examples would include cutting guides (above) and background texture (below). And I could envision a situation where there could be additional, intermediate Z, global layers, where page content needs to be inserted between particular pairs of global layers. In particular, I am thinking of a set of instructional slides representing a series of steps performed on some mechanism/design/org-chart which is replicated across all the slides. Successive slides would highlight particular portions of the mechanism and "bury" the rest. This is most easily accomplished by shuffling the Z order differently on different pages. The confusion/concern/curiosity I have been expressing in my last few contributions to this thread center around organization of per-page content. In a Publisher-style document, this is less of a concern. In a Designer-style document with diverse page/artboard contents, it is more of a concern. I agree with your comment that in most cases only a modest number of master global layers is needed. The appropriate number of per-page layers varies quite widely with what's on the page, and my objection earlier was to seeing the union of all the per-page layers all the time, on every page. If I am reading your respective replies correctly (and perhaps I am not), then you do not expect per-page layers to be visible on every page, while @fde101 does. Let me see if the answer to this question clarifies things: @fde101, are you proposing that all layers are global layers? Or merely that all master page layers are global layers? It's the consequences of the "all layers" decision that concern me.

This seems to be the statement I am getting hung up on. Are per-page layers nested inside global layers, or not? My reading (perhaps I am being too pedantic?) of @fde101 's comments is "yes", and of @thomaso 's comments is "no".

I did. I thought I was being clear that I did not care for having all layers be present on all pages. That is not a good tool to manage document content. In documents with diverse page (artboard) contents, the "natural" set of layers to organize one page is very different from the "natural" set of layers to organized a 2nd page. Consider a simple brochure or announcement which has primarily text and perhaps a few decorative graphics on the first page, and a complex vector illustration on the second page. Many of the layers used to construct the illustration have no place on the first page. And we really are talking layers, not groups of objects. Containers for things like guides, construction lines, grids, to take just one example. I understand perfectly well that not all content in a layer is replicated across all pages. But it does not help the user to show a bunch of layers with no purpose on the current page. It clutters the user interface, makes it harder to find the actual content, obscures the relevant structure of the page. So I am going to reiterate my desire for "varying sets of per-page layers without creating a set of global layers that is the union of all the per-page sets of layers".

CorelDRAW has had them for decades, but it only supports a single master page. So we can't look there for a good example of how they might interact with multiple masters. CorelDRAW also supports per-page layers which do not nest within and are completely independent of master page global layers, with the exception of Z stack order. For each page, master page global layes can be inserted/arranged in the master+page Z stack order as desired, perhaps quite differently from the order on other pages. Sometimes this is a great convenience, other times it is a tremendous nuisance to manage.

This is exactly what we are requesting global layers for - they provide that kind of grouping. See the video I posted above. I cannot reconcile these two statements, @fde101. Your earlier statement (2nd quote here) says that all global layers are on all spreads. That's not at all the same as supporting non-global layers which exist uniquely on one page, artboard or spread. Again, I am distinguishing layers (top level of the nesting hierarchy) from objects and groups of objects. In this document model, layers never nest within layers. Placing an object or group of objects on one spread is not at all the same as placing a distinct layer on one spread. Where is my misunderstanding of your proposal?

The content of a global layer is per-spread (or master), so you would still have the per-page layers, they would just be inside of global layers. Ah, that's where we diverge slightly. First, there is a need for global layers which contain the same content on each spread. I don't find it satisfactory to manually duplicate content within a global per-spread-content layer every time I add a new spread. The virtue of global same-content layers is that you get it right once, and it's guaranteed to be the same everywhere and if you update it, it gets updated everywhere. You never have to painstakingly inspect every single spread to make sure the supposedly-replicated content is actually replicated and not merely a close but out-of-date version. Second, when working in CorelDRAW on pages (which are more like artboards than spreads for the purposes of this discussion) it is frequently very convenient to have varying sets of per-page layers without creating a set of global layers that is the union of all the per-page sets of layers. And I am using layers in the "top level of the nesting hierarchy" sense, clearly distinguishing objects and groups of objects from layers. And I do want layers, not groups of objects, for several reasons related to visibility, print management and (ultimately, someday) automation scripting.

@fde101I am accustomed to applications which have both per-page and global layers. No layers nest within other layers; all layers are in the top layer of nesting hierarchy. Object and groups of objects are distinct from layers. The Z stack is determined first by layer order, then by object/group order within a layer. Obviously, I can work in other document models! But I would find the absence of per-page layers rather a nuisance!

@Old BruceIt's certainly not needed for every use case, but the example I gave above directly addresses your question. In that set of 50-some documents, I do indeed have things that need to be on each and every spread (cutting guides, background textures, etc.), and I need to turn them on or off individually when printing/exporting to generate the several variations of output from each document which comprise the package of digital files I sell.

Serif's Affinity team used to post a roadmap, but they got about 99% abusive responses from unprofessional users. So they have stopped discussing their development roadmap. Now we get what we get, and we learn about it in a beta release, no sooner. Having evaluated Scribus for myself, I'm entirely confident that the Affinity suite team is moving much faster than the Scribus team (although that's a terribly low bar to exceed). The major question for me is "Are Serif serious about addressing the professional market, or will they be content to stop with the casual desktop publishing market?" As we are still on version 1 of the entire Affinity suite, it's far too soon to say. However, it is not too soon to say that version 1 of AffPub does not provide quite a few professional features: scripting, tagged input, footnotes, bidirectional text, vertical text, robust running heads, robust color management and prepress support, plugin support, etc., etc. I used Ventura Publisher (nee GEM Publisher), before Corel consigned it to a deep, dark hole. VenPub 10 had some annoying bugs and needed some very significant fundamental upgrades (e.g., to handle Unicode) but it was a very nice system to use. When AffPub achieves the capabilities of VenPub, I will be pleased indeed. And AffPub has the potential to go quite a bit further.