Pyanepsion

I also think that the U+2029 probably comes from the end-of-paragraph symbol in the text box. However, I’ve left it in case it’s important. All the sequences shown are those discovered just after installing version 2.2.0.1986. I was working on a large index of several thousand references. I had resolved the unwanted line break before reporting it by modifying the sequence containing the semi-cadratine space. Whatever the After Topics sequence, it no longer appears in the form once it has been entered. It’s as if there’s a line break that doesn’t exist, but as you can see in the video, there’s still something selected.

I've used the default values in Affinity Publisher. Here is their conversion to UNICODE : Clic, Ctrl a, Ctrl c, Clic, Ctrl v, Alt U. labels-separators.mp4 After Topic: U+00A0U+003AU+0020U+0070U+002EU+0020 Between Items: U+002CU+2002U+2029 Between Ranges: U+2013U+200B Before References: U+002EU+0020U+2029 See: U+0056U+006FU+0069U+0072U+2029 See Also: U+0056U+006FU+0069U+0072U+0020U+0061U+0075U+0073U+0073U+0069U+2029 After See (Also): U+0020U+2029 After Refernces: U+0020 There is a caesura between U+200B and the next digit, or between U+2013 and U+200B (I don't know). In any case, it doesn't seem right that there should be a hyphenation because of the existence of U+200B.

v 2.2.0.1986 Dear developers, 😀 I’d like to start by thanking you for the recent improvements to the management of tags and separators in the index. It’s a very useful and well thought-out feature. However, here are a few remaining anomalies: The ‘Zero Width Space’ character does not behave correctly when used in fields when there is also an ‘En space’ between elements. The ‘After Topics’ sequence does not appear in the settings options once it has been entered. If necessary, I can send the complete file from which this screen shot was taken as a confidential file.

@PaoloT, @Oufti, I very much appreciate your feedback and I have the greatest respect for your experience and your choice to work in double-page format. However, I’d like to share a few observations based on my own experience that lead me to work preferably in single-page format. Odd and even layouts: Although double-page spreads offer a direct view of the differences between odd and even pages, I’ve found that working with single-page spreads makes it easier to manage headers and separate layouts. The application of even or odd layouts, despite its complexity without the use of external tools such as Excel that I mentioned, seems to be a limitation of the software rather than an intrinsic disadvantage of a single page mode. Layout conversion: Going from a double page to a single page can cause problems, especially when objects overlap the two pages. These objects may not fit correctly, creating inconsistencies. Take, for example, this red rectangle which now only appears on the even page, or this purple mirrored text which not only disappears from the final printout, but also loses its mirror effect and worse becomes inaccessible. double-simple.mp4 Object management and pagination: In the event of pagination changes or the introduction of a new layout, the single page seems to offer greater flexibility. The complications associated with changing page numbering or positioning seem to me to be more pronounced with a double-page layout. When a layout can be even or odd, working on a single page leaves me with one or two options on a single page, compared with two to four on a double page. I like the aesthetic and deductive advantages of the double page, particularly for a quick preview of the final rendering. For pragmatic reasons, and especially when the printer’s requirements are imperative, I remain convinced that starting with a single page currently reduces the risk of errors. I would like to stress my respect for your approach. Our discussion shows that each project has its own specificities and that it remains important to adopt the most appropriate method according to our context. Our discussions also highlighted that both methods have shortcomings due to current software. By resolving these shortcomings, Affinity will clearly gain a further advantage over InDesign.

Thank you, @Oufti, for your constructive comments. Before going any further, I'd like to focus on the heart of our discussion: the managing, in my opinion laborious, of page sectioning, as well as the restricted application, making it almost useless, of even and odd page layouts in Affinity Publisher. The distinction between single- and double-page master has no influence on how elements are anchored or "pinned" to a page, or how page breaks are handled. These functionalities remain constant, regardless of the choice of layout. With Affinity Publisher's current specificities, I'm convinced that it's best to start page layout in line with the specifications and constraints directly stated by the printer. This initial choice guides and conditions the entire process described here. Single or double layout: Although the tools you mention are relevant and widely adopted, they lose their relevance within the framework I've defined. My main concern is with the logic of starting with a double page layout, which could run counter to traditional conventions stipulating that certain pages, of which there are many in quality printing, must imperatively be on even or odd pages. Handling graphic elements: While working directly in double-page format offers improved legibility, it doesn't spare us the complications inherent in page layout, especially when graphic elements overlap two pages. If, for various reasons, a switch to single-page layout is requested, particularly by the printer, the risk of errors increases significantly. Content modification: Any intervention on double-page content, be it textual modification, the addition or deletion of certain pages (introductory, final or other), amplifies the potential for errors. I'd like to reiterate my respect for your approach, the advantages of which I can appreciate in certain specific contexts. My conviction remains nevertheless unchanged: to ensure a smooth, impeccable layout, it's wiser to always start by following the printer's guidelines, whether in single or double layout.

When creating a layout for a book, it’s essential to opt for a method that not only facilitates the process, but also minimizes the risk of errors. Based on the traditional observation that chapters start on an odd page, double-page layouts present a contradiction in that they start on the reverse (even) page. This requires additional conversion to respect these editorial conventions, which can prove to be an unnecessary waste of time. Then there are the 13 kinds of introductory pages, the 19 kinds of end-of-book pages – all standardized well – and the special pages included in the body of the book. This method of working with double-page layouts increases the risk of potential errors. Graphic elements or content spanning two pages may be incorrectly converted or adjusted when switching to a simple layout. Subsequent changes to the body of the text font may also affect the layout. As things stand, in order to guarantee a consistent, professional and error-free layout, I feel it’s wiser to start directly with a single-page layout, thus respecting editorial conventions and avoiding conversion steps that can prove laborious and risky. This choice ensures a more direct, more efficient and ultimately more reliable approach to producing quality work. On the other hand, the possibility of serializing even and odd page zones, and, of course, scripts, would reconcile the two methods, starting with a single page or double page.

The importance of a clear distinction between active and inactive elements is paramount for a user interface. This distinction must be consistently visible to ensure an optimal user experience. Examination of the screenshots and video does indeed show contrast, but it may not be sufficiently pronounced on all screens. Before considering individual solutions or screen adjustments, I think it’s essential to check whether this concern also exists in the standard version of the application, with identical settings. If the problem is specific to the beta version (as I understand it, this is not the case), it’s obvious that a fix is needed. If the problem also persists in the public version with the same settings, however, this could mean the need for designer intervention to optimize contrast management. The interface must offer a clear and constant distinction between its various elements, whatever the conditions of use. This guarantees not only a quality user experience, but also an efficient, error-free operation. To guide the user towards optimal parameterization, I would also recommend adding an illustrative situation to the parameterization menu, which is currently not offered.

Not working directly in the printer's format and constraints is of course possible with Affinity Publisher, and I did it at first, as it was the easiest process to carry out. However, I've come to realize that it's the wrong way to go about things, leading to errors and wasted time. Changing formats and constraints while working also increases the difficulty of repagination when adding or deleting pages.

Many printers request files formatted as single pages, rather than facing pages. This is independent of the software we use for page layout. However, as I mentioned earlier, the final determination of odd and even pages is often only made at the end of the layout process. This is because the final structure of the document is only known at this point. It can also happen that the customer requests repagination, as in the initial example, from 272 to 328 pages.

On several occasions I've noticed that the Affinity Publisher beta task is active, even though I haven't run it since powering up after a complete computer shutdown. I'm puzzled by this situation. The next time I notice this behavior, I'll obviously produce a dump. I hope this will help diagnose the phenomenon.

Hello, @jsfremont, First of all, it’s important to remember that beta versions are debug versions and may therefore contain bugs or instabilities. I notice that you use the expression ‘original beta version’. The association of the terms ‘beta’ and ‘original’ makes me wonder. It’s essential to understand that beta versions are under development, unlike original versions, also known as public versions. In any case, the report confirms that this is version 2.2.0 (1954) and is designed for X86-64 (64-bit) architecture on MacOS version 13.5. The thread that crashed is number 12, which belongs to an operation queue (NSOperationQueue). The main exception that led to the crash was EXC_CRASH (SIGABRT), which means that the application was interrupted unexpectedly. It seems that the application tried to process a drag-and-drop of one or more files ([DocumentView acceptDragFiles:atLocation:]). When initializing a URL from the file path, an exception was raised. This exception could be due to an attempt to access a null reference or some other type of memory-related error. Several threads are active, including the main thread (Thread 0) and others that handle events and network operations. There are also several threads that appear to be linked to the libopenexr library, probably used to process images in OpenEXR format. If the problem only affects a single PDF, as Hangman suggested, it could be that the file is corrupted or is in a specific, perhaps unusual, format. Sharing the file with the community could help identify and solve the problem. If the file contains confidential information, I recommend that you send it securely to the Affinity support team as soon as an administrator is available, and not in public. If, on the other hand, the problem is recurrent with all PDF files, this could indicate a problem with your configuration, a possible corruption of your Affinity Publisher Beta installation, or even a bug in this version. In this case, a video illustrating the problem would be a great help to the technical team. I hope it will help solve your problem. All the best!

v 2.2.0.1954 Dear colleagues, I'd like to bring to your attention a situation I've noticed regarding Affinity Publisher beta. Sometime, although I haven't started this application during the session, it seems to have been running in the background ever since the machine started up. This observation contrasts with the behavior of the other applications in the suite, namely Affinity Designer beta and Affinity Photo beta, which show no such persistent activity. This unsolicited operation of Affinity Publisher could have implications in terms of system efficiency and security. I would therefore appreciate it if you could verify and confirm whether this is a deliberate feature or a possible irregularity. Thank you for your feedback,

To be honest, no, because when I tried it in the past, I didn't get anywhere. What's more, I work on the whole text, not chapter by chapter.

Thank you, @MikeTO, for your research. Slow section creation: I've noticed that the slowness when creating a new section (specifying the start page number and section name) intensifies as the number of sections increases. My work generally involves books of between 300 and 700 pages. However, I have also encountered similar problems with a book of just 90 pages. Display problems when adding sections: When I add a new section, the list doesn't automatically scroll to display it. As a result, the newly created section quickly stays out of view. To make matters worse, the scrollbar in this window is particularly slow to respond, making navigation frustrating. Section title input field: In addition to being too narrow, this field is also poorly positioned, which is detrimental to ergonomics. Typing in this window is also unusually slow, adding another level of inefficiency to the task. Odd/even page delimitation: It seems to me that the current function was not designed by a DTP professional. As it stands, it applies to all odd and even pages in the document, which in practice is rarely feasible. Most books have special pages before and after the main content. Some pages may also be added or deleted over time, changing the even or odd page destination. The final layout of even and odd pages is therefore more likely to be carried out at the very end of the job, rather than at the beginning.

Dear colleagues and developers, I’d like to draw your attention to some specific issues encountered during the layout of a book, particularly in the book sectioning routine and the setting up of even and odd layouts. The aim of this feedback is to identify opportunities for improving our chaptering management. During a recent project, the layout of a book required a change from 272 to 328 pages. After adjusting the paragraph style and line spacing, I set about sectioning the book into its twenty chapters. This resulted in the creation of 22 sections, including introductory and end pages. Sectioning routine Among the difficulties encountered Interface slowness: Despite using a high-performance computer, interactions were neither instantaneous nor even fast, adding an unexpected delay to the task. Display limitations: When the number of sections exceeded the display capacity, the absence of an automatic refresh proved to be a major obstacle. Section title entry cell: The small size of this cell, coupled with the slowness of the entry, made the procedure laborious, not to say tedious. Delimiting of even and odd pages Once sectioning was complete, another difficulty lay in differentiating even and odd-numbered pages. The absence of a built-in function with zoning delimitation forced me to use an external solution, combining Excel and Notepad++, to manually generate a sequence of even pages between pages 10 and 324, a task that proved time-consuming and error-prone. In fact, without the option of delimiting the pages concerned by even and odd pages, the Even pages and Odd pages selections in the layout window are absolutely useless. 10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,74,76,78,80,82,84,86,88,90,92,94,96,98,100,102,104,106,108,110,112,114,116,118,120,122,124,126,128,130,132,134,136,138,140,142,144,146,148,150,152,154,156,158,160,162,164,166,168,170,172,174,176,178,180,182,184,186,188,190,192,194,196,198,200,202,204,206,208,210,212,214,216,218,220,222,224,226,228,230,232,234,236,238,240,242,244,246,248,250,252,254,256,258,260,262,264,266,268,270,272,274,276,278,280,282,284,286,288,290,292,294,296,298,300,302,304,306,308,310,312,314,316,318,320,322,324 And what a displeasing display! It is imperative to consider improvements in this area. After all, what’s a book layout without chaptering and the associated routines for sectioning and differentiating even and odd-numbered pages? I had already mentioned this problem when version 2 was released. The time has perhaps come to rectify this ergonomic issue, which is proving to be a handicap: these seemingly simplistic tasks took me almost an hour. Thank you for your attention and consideration. I remain at your disposal for any further discussion and clarification you may require. All the best,

@walt.farrell This is what I explained in the first message and what I show in the video. Note that the problem persists with version 2.2.0.1954.

Hello @NathanC I'm writing to share with you an example of a table of contents and an accompanying illustrative video. As you'll notice, line breaks are not being converted to spaces. In this specific instance, we've added a prefix (a number in this case) followed by a line break, all within a style meant for section titles. However, in the table of contents, this added text appears directly adjacent to the section title, without any intervening space. It would be more appropriate if a space were automatically inserted at this juncture. Moreover, I'd like to propose that users have the option to select the replacement character for converting line breaks, whether it be a particular space or a tab. This would allow for a more polished and professional presentation. Yours respectfully, Desktop 15-08-2023 20-12-44.mp4 toc-numbering.afpub

As previously mentioned, the book featured an initial table of contents outlining levels 1, 2 and 3. In addition, each chapter began with a table of contents highlighting levels 2, 3 and 4. During my work on a 52-page booklet divided into 4 chapters, I was faced with several challenges: Section inconsistency: The software had difficulty handling changes in pagination, including the addition or deletion of pages within a given section. The delimitation of content tables: I found it difficult to delimit content tables directly to a specific section, since the option referred to a table of contents afterwards, which didn’t yet exist, with the result that the entire book was listed each time, rather than just the section. A technical anomaly: an error message kept prompting me to update the main table of contents, which seemed to be in order. However, this update caused the software to freeze. This bug disappeared as it came. The section management interface: This still lacks ergonomics, particularly as regards the section title entry window, which is too small. Layout manipulation: The software does not yet allow you to define a specific range (for example, from page 6 to page 49) to apply layouts for even or odd-numbered pages. I’d like to highlight two positive aspects: Version 2.1 has given me the ability to resize text and graphics with ease, enabling me to go from A4 to A5 format. I was also able to produce the booklet much faster (a few hours instead of half a day) than with version 1.8.

v2.2.0.1931 Hello to the Affinity team and the community, When I structure a document with a line break between the chapter number and its title, the generated table of contents shows the number and title pasted in, with no intermediate space. Ideally, not only should a space be inserted to guarantee better legibility, but you should also be able to write out the sequence to be inserted. In the meantime, a workaround is to add this space just before the line break when creating the title style. Thank you for your attention to this malfunction and for your ongoing work. Best regards,

I did consider the solution of duplicating each section style from one chapter to the next, but that's obviously far too cumbersome. With 12 chapters, that's already 48 styles instead of 4. There's got to be another way!

When I asked my original question, it was because of a strange behaviour of the style: it didn’t retain the top-level format when saving the style. Fortunately, this problem seems to have corrected itself. My booklet currently has a general table of contents covering levels 1 to 3. I’d now like each chapter to open with a specific table of contents, detailing levels 2, 3 and 4 of that particular chapter. As shown in the image of the table of contents book in chapter 4 in the first message. Level 1 Level 2 Level 3 Level 4

Hello everyone, I'm trying to adapt the formatting of a document using the numbering structure of the APA Style Guide manual itself to a document. I can't create level 4 correctly. Here's the numbering structure I'm trying to reproduce: Level 1: Chapters, typically numbered from 1 to 12. We are in chapter 4. Level 2: Some chapters have groupings, such as "EFFECTIVE SCHOLARLY WRITING" in chapter 4. Level 3: Sub-groupings of Level 2, such as "Continuity and Flow", same chapter 4. Level 4: At this level, the numbering ignores the previous groupings and could, for example, extend from 4.1 to 4.30. My main concern is the automatic configuration of Level 4 numbering in Affinity. If you have any recommendations or solutions for this layout, I'd be grateful if you'd share them. Edit: Corrected. I don't know why, but the new style 4 didn't want to depend on style 3, and remained dependent on the Numbered List style from which I had originally removed it.

I confirm. A referenced image, i.e. one stored in a separate file and loaded by the src attribute of the <img> tag, poses no problem. It's when the source of this image is integrated into the source that we get a rather annoying error message. More explanation in this message :

@Pšenda, Superb. Which version of the Affinity suite did you use? Could you provide the source?

Hello, @Hangman, I'd put it another way. Here are a few points to consider: Impact on Rendering: The error apparently doesn't affect the way the page is rendered in current browsers. Its impact can be considered minor. However, this could change with future browser updates. Maintenance and Future Development: Ignoring validation errors can make code more difficult to maintain or extend in the future, especially if other people are working on the code. Compatibility: While the error may not affect modern browsers, it can cause problems in some older or less common browsers. Good Practice and Professionalism: Following web standards is generally considered good practice and reflects a certain level of professionalism. Ignoring validation errors can give a bad impression to other developers or stakeholders. Natural SEO: Although less likely with this particular error, some validation errors can potentially have an impact on a site's SEO. In our case, since we're dealing with resources, we encountered display errors with certain online tools. In short, the actual impact of this error may depend on various factors such as the target audience, the browsers supported, and the specific needs of the site. It may be wise to correct the error even if it doesn't affect the experience of the majority of users or the site's objectives.