Lagarto

What is strange is that you seem to have received different kinds of error message related to the same problem (inability to save an already saved file), at least one related to user privileges, and one related to internal error. One thing that could poterntially have effect on an application's ability to save files that it has opened is having a background task that e.g. creates backup copies of documents, or an antivirus application that controls access of apps to certain locations on the system. For that purpose there might be point in saving in a location on your D drive that such apps are not watching for their operations. .If you typically save to a custom location on your D drive, does the problem also appear if you save somewhere along your "My documents" folder path? Do you have "My documents" (the system default folder for user documents) still on you C drive, or have you moved its location to the D drive?

Do you mean reference point according to which objects are aligned to? I would like to see Affinity apps to have simiar thing as InDesign or Illustrator, where the Control key (or Alt key, in Illustrator) lets you pick the object (amongst selected objects) that is used as a reference point when aligning objects. In Affinity Publisher you can achieve something like this by selecting "First selected" or "Last selected" as an alignment option. But other than that, I have not noticed problems with being able to center align objects (in relation to center point of selection, page/spread edges, or margins).

Ok, thanks. The thing is that the table auto-adjusment problem applies to both beta and the release version, and the most active users (or testers, to use the proper term) are likely to run the most recent beta. Reporting to one forum (the most recent one) should ideally have some kind of feedback from the developers, without a need to copy the post to parallel forums, or without a need to test whether a specific issue can be reproduced also when using the release version, and/or a macOs version. But I guess this is a matter of limited resources, and the focus is at this point somewhere else But if the code base is common, I can be pretty confident that the problems posted to this forum have been experienced also with release (and macOS) versions, and have accordinbly been properly acknowledged.. EDIT: Ok, thanks: corss posting...

The serialization issues are actually one of my main worries with Affinity apps. Serif has shown great promise feature-wise, but the bread-and-butter things seem to need some serious attention. Personally I am not too enthusiastic about the concept of across-editing capabilities and common file format, as easy exchange of data has not been much of a worry when using Adobe apps. Editing is never far away, and e.g. most of the Illustrator objects can be copied across to InDesign using the Clipboard, etc. But file corruption is a serious problem, and securing that you do not easily lose your job is one thing that Adobe has done right, starting from CS v.1 (those who are old enough to remember what it used to be like with PageMaker know what I am talking about). So that's why I have been curious to know what could be the reason for the problems you have experienced. I have not experienced any i/o related problems with Affinity apps myself, and I have not seen many posts that report these kinds of problems, but there are posts that report problems with unexpectedly big file sizes, linking/embedding and especially importing files from cloud resources, problems related to across editing, etc., so this is one of the issues that I am following very closely. I'd appreciate if you could have patience and continue troubleshooting these issues for a while, as I think this could help us all to have a true alternative in this business!

I wonder if we are reporting to an unread forum? Nobobdy at Serif seems to read the beta forum (at least on Windows side), even if there is a new beta... the post for the beta release had a request to post bug reports found in this release to a beta Mac forum, but I thought this was just an omission. But I have posted a beta-only specific bug related to text wrapping but no one has acknowledged it even this is a definite bug. I guess there is something more urgent at hand... Same with the topic post which is an 100% reproducile bug. Maybe it has already been reported on the Mac forum. The key customers...

I don't mind that being possible but it should ideally be indicated somehow. It has always been a kind of a nuisance in InDesign that you need to change to page edge alignment when you have a grouped or single object selected as that is basically an obvious choice.

I think that what it actually does (after you have pressed Ctrl+G to group), it first cancels that alignments performed, then groups the objects, but when you subsequently close the flyout just clicking outside of the flyout (without clciking Cancel or Ok), it actually applies the default vertical aignment option, which could be aligning to top of the page edge, or bottom, depending what has been done last, and now that you have a group, silently applies alignment in relation to page edges. In many ways, this is an odd mix of modal and non-modal controls. In a non-modal control you should not need to use Ok/Apply button if the alignment controls already perform an action, and cancel should be done by going back with the Undo history. In a modal control, all transformations with actual objects should be previews, which should automatically be canceled, if the user does not actually "Apply" the changes. Simply going away should not be allowed as some kind of an indeterminate "Ok", as it is now, and if it is, then the flyout should either be "pre-emptive" and disallow conflicting shortcuts (like grouping), OR, be aware and acknowledge that the user can e.g. group the objects in the middle of the alignment operation. We do not need Apple to know that

This is continuing an off topic discussion but I could not resist on commenting this. I think the usefulness of paragraph composing depends much on the language, and also efficacy of the hyphenation algorithm. French has long words, but it also has articles, prepositions and short words to allow some room for alternative compositions. My mother tongue, Finnish is quite hopeless with long compound words and no articles and prepositions, so there is really no going back and use single line composer. That said, it is always a great pain to need to edit the text (e.g., change hyphenation), as that often means recomposition of the whole paragraph. Basically I use single-line compose only with jobs where I know beforehand that there will be much editing once the basicl layout is accomplished. But mediocre hyphenation algorithm combined with absence of paragraph composer makes use of Affinity Publisher a hard choice for narrow-column long-text book jobs in Finnish language. EDIT: Forgot to add that you are in an exceptional position with Bible publshing that you're not likely to get edits in the text that is once already carefully typeset so it is really a no brainer choice to use the paragraph composer :-)

It is of course also partly a question of where you come: InDesign users are accustomed to using alignment panel that operates without needing to click Ok to apply alignments, and each click in the alignment button is recorded in the Undo history. I think this is more intuitive. It would be another thing if alignments really were just previews, and would not be applied unless Ok button is clickd or Enter is really pressed.

I think that it is more accurate to say that pressing Cancel button or Escape key are the only methods of canceling the operation that has already been applied. EDIT: In addition to using any shortcut key (like pressing Ctrl+G for grouping).

What is the purpose of the Ok button, if the transformation (alignments) are applied if you just click outside of the Alignment window? This is not a modal window so one does not think that what is shown on the page (actual alignments) are just previews. And in fact, they are not. This is bad UI design. EDIT: I mean, clicking the alignment buttons already applies the changes. Clicking Undo cancels all actions performed so there is purpose for that button. But what is the purpose of the Ok button (just closing the window).

No, it behaves erroneously, as described. The problem is that the grouping action Ctrl+G does not behave correcly while the Align window is open. If you close the Align window and then press Ctrl+G, the objects are grouped. Also, the alignment steps performed while the Alignment windos is open, are not correcly tracked in Undo history (you just get back to the starting position and cannot undo one by one the align operations performed). Odd alignments happen, as described in the post, if you continue aligning after the Ctrl+G "grouping". Actually what the app seems to do, it first cancels all performed alignments when pressing Ctrl+G and then groups the objects. If you continue aligning, it aligns the group in relation to page boundaries (even if "selected boundaries" is the active alignment option, but this seems to be intentional).

Hope you manage to resolve the problem at some time. It sounds as if it could be a drive related yet you have not experienced problems with other software, and you mentioned you have run a diganostics tool on your drives. If you have separate physical disks for your C and D drive (rather than one physical disk partitioned to have two drives), I'd still try to saving the .afpub files on your C drive for a while to see if this resolves the problem.

Does not really seem the problem could be related to "non-ascii" characters in file names (and at least in the installation path), but one never knows (e.g., InDesign may still fail to recognize an image file as a valid TIFF file if its file name contains a non-ascii character), so it was worth a try. Just curiois: do you make much cross editing within Affinity apps, or have you experienced these problems also when you have edited the file with just Publisher?

I noticed the following in the flix list of latest Designer and Photo beta (the equivalent beta has not been released for Publisher, yet): "Fixed crash when install location contains a non-ASCII character" Do you happen to have installed Publisher in custom location (I think that older Windows OS versions might also have localized standard paths)?

Still related to the same feature: the opacity setting that is saved as part of the color definition, is reflected in the color swatch when they are viewed as a list, but not, if they are viewed as boxes. The opacity percentage is however shown also with boxes when you hover mouse pointer over the box. Note that the transparency is rendered similarly in these two view modes disregarding the UI bakground color (Dark or Light).

Note that circle in the example is encoded as... style="opacity:0.5;vector-effect:none;fill:#333333;fill-opacity:1;stroke:none;stroke-width:0.5;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" ...so it has both fill and outline specific definition (set to 1 here), and a generic definition for just ¨opacity', and this is correcly interpreted for graphic objects but not for text.

Related to this: transparency should ideally be handled as a separate feature from colors, even if it naturally affects the color. But the colors that are produced because of interaction of colored objects with transparencies against different backgrounds cannot be visualized meaningfully with a color. E.g., now if an object has 50% opacity defined, and the user clicks another color well in the Colors palette, the transparency changes back to 100%, which is not what is normally wanted. The transparency is the desired effect in its own right no matter what is the object color involved in the effect. It might need to be adjusted because of change of color, but ithe object's transparency setting should nevertheless stay the same even if its color is changed. Transparency effect still misses the percentage box in certain places, at least in the context of Text Frame panel, and it would be more important to have the editable box than a slider and a well which tries to visualize the effect. EDIT: Just remembered that Affinity apps handle object transparency also via layer (which is in practice an object property), and separately via Fill effect and Outline effect, so there is a way to apply a global transparency for the object, which is retained when its color is changed. Opacity is just an additional property of a color in Affinity apps. It may get confusing, but it may be handy to have opacity defined as a swatch property. In this perspective, the transparency should probably be somehow visualized. But ideally consistently so that the definition looks identical in all panels.

Personally I do not think that it is so important to visualize the effect ot transparency in a color well, but if it is done, I think it should be done consistently in the Gradient panel, and the Color panel. Now if the user has dark UI, the transparency is shown against dark gray background in the Gradients panel, and against the light gray in the Colors panel. My preference would be having the transparency/opacity shown simply as a percentage value whereever it is defined, and show the actual effect against the background only in the object. Tints and shades, however, should be reflected in the color well (but not in the swatch, unless a new swatch is created based on tint/shade).

The insertion point is indeed in the correct place (which can be noticed if you just click Find and subsequently type in a character), but it is displayed as if it were at the end of the line (and before the break symbol). One might expect to see it blinking in the beginning of the line (?).

Did I undestand correctly that you have experienced this error with very small files, as well (e.g., with newly created files where you have placed the kinds of single eps or ai files that you had attached in your post)? I can imagine that complex files may cause different kinds of problems, but if you have constantly experienced corruption problems also with small, newly created files, and you have run disk diagnostics on your drive, then there might be something wrong with the installation or Affinity-related registry entries, so uninstall/reinstall might help.

Interestingly, when the SVG file (svg_transparencies_from_ai.svg) attached above is opened in Affinity Publisher, and the transparency values have been reapplied manually, and the document is then exported as svg (with default "Export" options), the file opens correctly in Affinity Publisher, and renders also correctly e.g. in Chrome, but Illustrator messes up the transparencies! So it seems to be pretty much a matter of encoding, and ability to support different encoding methods. Affinity produced svg (attached) opened in Illustrator (CS6): ...and in Affinity Publisher: svg_transparencies_from_apub.svg

The same happens when opening SVG 1.1 format files produced by Illustrator. The text imports as text (if the font used is installed on the system), but as opaque. The source has the opacity value correctly applied, and when opening this in Illustrator, the text is transparent. svg_transparencies_from_ai.svg svg_transparencies.ai

Thanks for the explanations. Did I understand correctly that the safe method to encode ligatures is using the "concatenation" method, e.g. (U+0066+0069) for the ligature "fi", and (U+0074+0069) for the ligature "ti", rather than referring the existing code point for the glyph itself, "fi" (FB01), or "ti" (whereever that is placed in the font, whether subsetted or not)? Anyway, it was good to see that PDF-XChange (Editor Plus) can actually edit the text as if in text editor no matter how the ligatures are encoded, that is I can copy paste the actual Affinity Publisher created "ti" ligatures without problems, while I cannot do this in Adobe Acrobat (or any other tool, as when the PDF is opened, the "ti" won't be rendered, even in Affinity Publisher, and copy pasting from one app to another is guaranteed to fail when custom encoding is used). I had to purchase this tool recently because InDesign could not produce an acceptable PDF/A archive format for a thesis (!). I have now used the tool to automatically generate hierarchical bookmarks from a TOC (quite useful with Affinity Publisher), so it has proven to be quite a capable PDF tool!

Actually it could also be so that Affinity Publisher specifically uses the actual ligature codepoints, while InDesign uses ligature attributes, and just "ti" and "tt" as single characters. So whether a ligature is shown or not, depends on the viewer (i.e., if hardcoded glyph, all viewers can show it, if an attribute, the viewer must support the ligature as a feature), and whether a ligature codepoint is used as a glyph or not, when copy pasted, depends on the destination software (i.e., whether the destination software decomposes the hardcoded glyph as separate characters, or supports use of hardcoded ligature glyph itself not as an attribute but glyph). See below how PDF-XChange can edit and copy the selected ligature in the PDF created with Affinity Publisher ("ti" as a hard-coded glyph), which PDF-XChange can copy paste to duplicate it: ...and below editing the PDF created by InDesign, where "t" and "i" are separate glyphs which are rendered as ligature glyph "ti" because it has been coded as formatting attribute: Just guessing. I do not know internals of PDF encoding, but this kind of makes sense. EDIT: More guessing... The "attribute" status seems to be achieved by encoding the composing character codes to follow each other, e.g. "t" + "i", which the rendering application maps to the actual ligature glyph, if it supports the feature, and the font has the corresponding iigature glyph; and as separate glyphs "t" and "i", if it there is no support. Affinity Publisher seems to refer directly the ligature glyph code, so that when it is copy pasted it does not necessarily get correctly rendered in the destination app. See below ligatures_apub2.pdf, which has ligature "fi" added in the text. When this text is copy pasted back to Affinity Publisher (or Illustrator, or InDesign, etc), the "fi" ligature will be correctly rendered (either as ligature "fi" or separate "f" and "i", depdending on whether standard ligature atttibute is turned on in the destination app), but not "ti" (which is not supported in most fonts, but will not be rendered even if Calibri font, that supports it, is retained in the destination app). Don't know whether it is a question of these two ligatures having been encoded differently, or whether both are "hard coded" (referring directly the ligature glyphs), and only "fi" gets mapped to ligature "attribute" by encoding it as "f" + "i" (U+0066+0069). Anyway, concatenating the composing characters seems to be the safer method, as it is not dependent on the font's capabilities, or the rendeing application's ability to use ligature glyphs.. ligatures_apub2.pdf