Pyanepsion

It's a translation error from French to English. I meant “a document format”. I'll modify the initial message.

A dedicated palette has been created in the Swatches menu, with each color representing the collection to which the document belongs. The main color is applied to various elements of the document, such as the background of text frames, text color, rectangles, borders, etc. Currently, we have to manually modify all occurrences of this color in styles or directly on the objects concerned. Here's a quick example to illustrate the process, with two versions. test-united-color.afpub

Very large documents can be opened, including those with many images and fonts. However, the machine must have sufficient memory and storage capacity, and the PDF file must comply with the PDF standard. Also: Performance settings must be sufficient. If a link is external and uses an Affinity application, the external file must be up to date. Fonts and files must be correct and present. Correct what the preflight says. Please note: the number of pages and file size may be limited by the recipient's department.

Hello everyone, We’re currently working with a document format that uses a specific colour (applied to the background, characters, borders, etc.), selected from a palette defined according to the nature of the document. Would it be possible to modify this colour in a single operation for all the elements concerned in the document? Thank you in advance for your expert advice. Best regards,

Hello everyone, When managing complex documents, you often need to find a specific note, for example, note 253. This currently involves browsing the entire document or searching for a textual occurrence. This process can become particularly laborious when the note in question uses a foreign writing format (उदाहरणम् in Sanskrit) or a generic annotation (such as ‘ibid’). The greater the number of notes, the more time-consuming this task becomes. When you want to examine notes one by one, or return to a previous note, there’s no simple, straightforward way of doing so. It’s in this context that a note browser could greatly enhance the user experience. Such a tool would offer several advantages: Optimized annotation management: For voluminous projects such as thesis, technical or academic books, a note browser would enable easy navigation between annotations, without having to manually browse the document. This would boost productivity, especially for documents with a large number of references. Easier organization and revision: Whether it’s footnotes, endnotes or side notes, as well as internal comments, a centralized tool would facilitate their consultation, verification and modification. By providing access to all notes in one place, it would considerably simplify editing and cross-reference management. Contrary to what you might think, a note browser would not duplicate current functions, but would meet a specific need that is already being felt in text editors such as Word. It would also be an innovation ahead of competitors such as QuarkXPress and InDesign, giving Affinity Publisher a clear competitive edge. However, care will have to be taken to ensure that the ergonomics are well thought-out, so as to avoid unnecessary interface overload, while maximizing the tool's efficiency. Thank you in advance for your attention to this suggestion.

Hello everyone, In publishing, it's common practice for the Quick Response Codes (QR Codes) to be represented in black on a white background, with a white border, in order to distinguish them from the cover. However, unless I'm mistaken, it seems that only the color of the blocks can currently be modified. This forces users to manually create a background rectangle and outline for each QR Code, adding extra steps to the creation process. I therefore propose adding an option to directly customize the border and background of QR Codes. This feature would offer greater flexibility in harmonizing these elements with the visual identity of projects, and would save precious time thanks to the integration of presets. Thank you in advance for your attention to this suggestion.

The French message uses an unusual formulation. It's more like: incompatible characters have been used. Similarly, the window (and menu) don't support fonts (Arial, Cambria Math, Kokila, etc.), but fonts (Times New Roman Bold, Times New Roman Italic, etc.). Adding a link or a button could indeed be the solution.

Thank you for your reply. The error message did indeed mislead me, even after using Preflight. I had temporarily put aside the typography issue to concentrate solely on the footnotes. Suggested improvements: Clearer error message: The “Unsupported characters use” message associated with the Locate button is misleading. A more explicit message, such as “Incompatible characters. See Preflight” would avoid this misunderstanding. Improved navigation: more intuitive navigation, as in Preflight or the Resource Manager, would allow you to view all occurrences of a font at once. At present, you have to scroll through the entire document without any real visibility, and if you are interrupted, you have to start all over again. These adjustments would make font management more efficient, especially for multilingual documents.

Hi, everybody Context When importing a Word document into Affinity Publisher, containing several footnotes written in various writing systems, I used the Bodoni MT font for the footnote style, in its regular, bold and italic variants. However, the Font Manager reported a character incompatibility with Bodoni MT Regular, while the Bodoni MT Italic and Bodoni MT Bold styles posed no problems. Observed behavior Here’s the path that explains the difficulties encountered. When I clicked on the Locate button to identify incompatible typefaces, the tool directed me straight to the first footnote. Yet this footnote seemed to contain only Bodoni MT Regular text. Suspecting the presence of an invisible character or some other anomaly, I carried out a manual check without finding anything suspicious. To get around this problem, I selected the entire note and manually reapplied the font style. This allowed me to correct this note and move on to the next, repeating the process for several other footnotes. However, after interrupting and resuming my work session, the Font Manager again redirected me to the first footnote, which had already been corrected. Problem solved After further analysis, it was found that the root of the problem lay in the non-Latin characters present in some footnotes. By changing the font used for these non-Latin terms, the incompatibility alerts disappeared, and the tool stopped reporting these errors. Suggestions for improvement To improve the user experience and optimize this tool, here are a few suggestions for the Font Manager: Precise identification: The tool should be able to specifically identify incompatible characters or problematic sections, rather than systematically referring to the first occurrence of the style concerned. Better management of non-Latin scripts: Distinguish more clearly between incompatibilities linked to non-Latin writing systems and propose alternative fonts adapted to the characters detected, like in preflight. Navigation in localization: Add a forward-backward navigation system to the Locate functionality, rather than one-way navigation. These improvements would increase the tool's accuracy, reduce the time needed for manual error correction and make the process more user-friendly and efficient.

Your explanation is clear and this is indeed what I tried to highlight in my video. However, from the user’s point of view, the problem remains the same: we end up with either empty pages at the end of the document, or missing pages. The aim of this bug report is, therefore, to consider improvements to this routine, to better meet the practical needs of users. The aim is not simply to justify the current, obvious behavior, but rather to explore ways of avoiding these inconsistencies in the final layout, which can be very costly.

@Hangman I understand the argument, but the situation is more complex. When converting to endnotes, the automatic addition of an empty page is already problematic. - If the user deletes this empty page, it obviously creates a gap when returning to footnotes, which can easily go unnoticed. - In practice, with large documents, when starting from endnotes and converting to footnotes, it is possible for text to overflow without being immediately detected, resulting in truncated text. @MikeTO, @Hangman The choice of converting a note format to itself should be completely hidden, as over time many users no longer pay attention to the button text. This could lead to repeated errors and a loss of efficiency, as the operation performed would be useless and potentially confusing.

v2.5.5.2636, and before Hello, An empty page is systematically added towards the end of the document when converting footnotes to endnotes, and similarly when converting endnotes to footnotes (see video and attached file). notes.mp4 It is also possible to convert a notes format to itself, which not only appears useless, but can also lead to errors if you think the conversion has been carried out correctly. Finally, when deleting an empty page containing endnotes, then converting to footnotes, text overruns occur. Corrective actions expected: Remove the automatic addition of the empty page when converting notes. Hide the possibility of converting the note format to itself. Add missing pages after conversion to avoid loss of information. Please do not hesitate to contact me should you require any further information. notes.afpub

@Old Bruce I looked at your text. In France, we were still writing in this format just over a hundred years ago. It’s obviously a real typographic headache. 🟩 Managing punctuation pairs is a real headache these days, regardless of the language. A verification tool that understands these rules would be extremely useful. ⁂ For those who are interested… The evolution of dialogue typography The typographic evolution of dialogue in France is a subject that has fascinated me. It reflects cultural, linguistic, and technical developments, as well as the ongoing battle between English and French influences. Here’s an overview of the main stages and periods in the typographic evolution of dialogue in the French style (with a bit about the English style, which I’m less familiar with): 1. Medieval period (before the 15th century) Absence of distinctly typographed dialogue: In medieval manuscripts, dialogues were not differentiated from the rest of the text. They were integrated into the body of the text without any specific markings, sometimes using abbreviations or symbols to indicate changes in speakers. 2. Invention of printing (15th century) Birth of modern typography: With Gutenberg's invention of printing around 1450, dialogues began to be printed. However, they were still barely distinguishable from the rest of the text, often inserted without quotation marks or dashes. Dialogues might be indicated by paragraph changes or by capitalized initial letters. 3. 16th-17th centuries Appearance of quotation marks: During the 16th century, quotation marks began to appear in France, initially in the form of double commas at the bottom of a line to enclose quotations or dialogue. However, their use remained inconsistent. Use of dashes: From the 17th century onwards, dashes began to be used to indicate the beginning of lines in dialogue. This practice gradually became more common, particularly in the theater. 4. Eighteenth century Standardization of quotation marks: Quotation marks became increasingly common for framing dialogue, thanks in particular to the influence of the Académie française and Parisian printers. Quotation marks took on a more standardized form, at the top of the line (“…”), to indicate direct speech. More dashes: The use of dashes to introduce lines in dialogue became almost systematic, especially in literary works such as novels and plays. 5. 19th century Affirmation of the modern model: The 19th century saw the spread of the system we know today: dialogues were introduced by dashes or framed by quotation marks. Dashes were mostly used in novels to mark each new line, while quotation marks were used to frame specific sentences or passages. Typographic codification: Typographic practices became standardized thanks to advances in printing technology and efforts by publishing houses to establish precise typographical rules. 6. 20th century Clarification of typographic rules: The 20th century saw the definitive establishment of current standards for dialogue typography in France. French quotation marks (« … ») were preferred over English quotation marks (“…”), although the latter began to appear in certain contexts, particularly in the translation of foreign books. Typographic experiments: With the literary avant-garde (particularly the Nouveau Roman), some authors began to experiment with typography, playing with the presentation of dialogue (absence of dashes, use of italics, etc.) to create particular stylistic or narrative effects. 7. 21st century Diversification of practices: The advent of the typewriter and later computers introduced the use of straight quotation marks ("…"), which became widespread for convenience. Although modern software automatically corrects this issue in many cases, it is not infallible. For example, in the Affinity suite, text formatting in Publisher differs from that in Photo and Designer, where typographical errors linked to keyboard use are not always corrected, leading to inconsistencies. Anglo-Saxon influence: The influence of Anglo-Saxon standards, marked by the use of straight quotation marks and other typographic conventions, is becoming more pronounced among certain authors steeped in American literature. This trend forces French-language typographers to make tedious adjustments to bring texts in line with French conventions, which are simpler and more restrained. ⁂ Integrating a function capable of correctly managing typographical pairs of any kind would be a major asset for the Suite, particularly as it is software closely linked to writing. 📌 The example of programming tools such as Notepad++, Visual Studio Code, and PhpStorm, which are beginning to offer these features as part of the coding process, demonstrates the importance of such improvements. Adding such a feature to the Suite would not only be beneficial but essential to ensuring consistent, professional typography.

@lacerto In my humble opinion, it is essential to differentiate between the resolution of a specific case, designed to respond to a particular situation, and that of a company which aims to create sustainable solutions for a wide audience, by generalising the concept. The first question to ask is to precisely define the potential target, and then identify the resources and skills needed to achieve this objective. How many times have I heard that certain tasks were humanly impossible to achieve, only to see those same tasks successfully accomplished? You have, for example, found a solution by placing vowels at the beginning or end of a line, even though, unless I'm mistaken, this is not recommended in Finnish. For my part, I've automated the colouring of delimiters and their content to make it easier to detect missing elements. However, this only reduces the time needed for the review. I think it would be a good idea to continue the analysis to allow the software to report only the isolated or forgotten delimiter. So, yes, I firmly believe that more advanced automation is possible. The main obstacle will be wanting it. As for the market, it seems vast.

No. You just have to want to do it, and it's of obvious interest to all those who have to process the texts. I haven't gone any further, but you can already see that errors are immediately visually easier to detect, so image a routine that immediately tells you where the errors are. This also existed in French during the transition period to en dashes.