Daniel Gibert

I can convert it on any other external text processor, but always prefer to do it directly on Publisher, for work speeding. Also, much of the work involve text in tables, graphics, and even complex text with all posible caps cases included and mixed in horribly bad formated word, powerpoint or excel documents, where converting the text will be painful and slow (Text boxes, boxes in boxes, groups, groups in groups…) If it where for an ocasional sentence or paragraph… but my customers have very "vicious" issues with the all-caps. Publisher do this pretty well except for the "Y" and depending on other software for case-modification will broke our already congested workflow a lot. And due to the amount of "vice" from the original text, manual rewritting is discarded. It is much better to do it on Publisher once correctly placed in the clean and correct layout. Sorry, long rant on customer's bad text profilaxis. Having a bad day here today.

Hi @Dan C Region and language on OS: Spain/Spanish Publisher in Spanish MacOS Built In dictionaries only It happens on any font, system or custom installed . Important to help refine the issue: It happens when the text originally is written in all uppercase (In your example the none text is written in lowercase directly). Our customers have the annoying idea that sending us the text in all caps makes it more prominent. We use the Sentence Case to convert the text to normal sentence from the original uppercase text. Publisher does it pretty good except for the "Y" Maybe is for this that you are getting the "y" correctly. Try converting from all caps text. Hope this helps you.

Hi there. When doing a sentence case capitalisation in Spanish language, there is a constant error on which the "Y" is always set as uppercase. Reading you official description of the sentence case function, it seems that… is it considering "Y" as a proper noun? Example: NOVEDADES EN LAS NUEVAS VERSIONES DE AFFINITY Y OTRAS COSAS INTERESANTES results in: Novedades en las nuevas versiones de affinity Y otras cosas interesantes (On a merry anecdote, Affinity does not think Affinity is as a proper noun ) It is not a terrible error, but having in mind the hideous trend of our customers to write all titles and subtitles and even paragraphs in all caps, it adds extra work to check for the rogue Y's. Cheers to the team!

This was noticed as I was sending a job in two languages (you send one document for each language and are printed half upside down so the document has a correct cover for each language). Printshop noticed that they can't do imposition because documents where not centered vertically so bleeding and cut marks didn't match on turning the 2nd language upside-down, After studying the issue, we have noticed that if you only set trim and registration marks, it centers perfectly, but if you add colour bars and page info, the content gets sightly displaced. Not sure what of the two is causing the misaligning. On regular jobs this will be not an issue, but unfortunately here we do a lot of bilingual design that requires that kind of printing. The used setting are X-1a:2003 with all printing marks active. The solving settings are using just cut and register markings. If you need documents to check it, i can provide through a Dropbox upload link (Sorry, I can't post it here due to customer request)

I can confirm that in Spanish the hyphenation makes a lot of incorrect/forbidden partitions (And it makes it horribly wrong, like breaking sylabes), that only happens on the Affinity apps. In fact, I desisted on using the Spanish hyphen rules and I use the ones for Latin, because it works much better.

I don't understand why most people never include an example file. It is easy to do and it helps a lot to @Serif team. It took me a minute to prepare the example attached. That and to explain steps to reproduce which is a must.

Sometimes, when using tables with text rotated 90 or 270 º the cell height is randomly increased, resulting in a taller then needed cell that cannot be reduced in height. It does not happens on single words, only on paragraphs. And it happens at a random. You are writting the text in cells and all is going fine and on a random cell the spacing is added and all row gets the extra height. Tried both with existing and with complete new tables. See example in attached file. The upper table has the cell issue on the first row. The second one use single words so it does not happens until you add more words to a cell. It only happens in vertically rotated cells cell-height-rotated-content.afpub

How did I not noticed this wonder before? you made my day! If true is just what we need. Thanks for sharing. Now we need it asap. They say at some point after 1.9 release… we are at 1.10…

Hi. It is in preferences > General It is the 3rd from the bottom. I have it in Spanish but in English should be something like "Prefer to keep the selection after deletion" or similar. Simply deactivate it.

Hi Dan C. Thanks for the information. I understand the process and now I know what to expect. Anyway, this is a horrible behaviour for the PDF output, because it destroys completely the WYSIWYG. If Publisher is able to calculate a CMYK preview, and export a correct CMYK PDF for that adjusted RGB image, it should also be able to correctly convert to RGB that same CMYK output. (And viceversa) This is something that is could have a good improvement on the future. I'll cope with it, but i find it somehow wrong. Fortunately is something that does not happen frequently on the type of work I do. Rarely apply color correction directly as adjust in Publisher, I normally process the images in photo persona. Just a case on which I needed to do it as layer adjust and export on RGB and CMYK. Thanks for explaining it anyway.

Hello. When exporting to RGB PDF from a CMYK document with images with shadow/light adjustment, the final result in PDF is burned images. Exporting to X1A or any other CMYK setting works well. It seems like an error on converting to RGB. I've attached the Publisher document and the incorrect pdf export. Steps to reproduce: Insert image, trim it and apply a shadow/light correction adjustment (Tried both linked an embedded) Export to cmyk pdf: exports correctly Export to RGB pdf: images appear extremely burned. rgb export.pdf rgb export issue.afpub

Oh my! our customer just ordered us to rearrange a whole catalogue, so we will copypasting content from different files which share style naming. The only difference on those styles is the accent color, but be prepared to have thousands of iterations of styles as it is adding a new numbered style each time we paste a single item. This is going to be a nightmare. Imagine, 12 documents, 500 pages, 3500 products products going from one to another file and Publisher not replacing pasted styles with the ones already existing the target. It is gonna be literally hours of cleaning and re-stilyng. Please, Affinity, add an option to use the already existing styles on pasting. This is gonna be horrible. Just as simple as that: Use the existing style if the name match on pasting.

Since 1.10.4 the width of the right Studio doesn't return to it's former state after exiting preflight panel. Preflight is a much wider panel that makes the studio wider when you select it. In previous versions of Publisher and in the left panel in the current one, when you exit the panel choosing any other one on the same studio, the width returns to it's former user set width, something that it is not happening now. You need to manually adjust the width or restore your custom layout from the menu. Reproduction steps: Have a right side studio with preflight panel in it, and custom width Enter the Preflight panel, the studio widens to fit the large panel Select any other panel in the studio, the preflight width remains Try this with the left studio, the panel retracts to former size after exiting preflight panel Affinity Publisher 1.10.4 MacOS 12.1

Hi Pedrober. It seems that the version you shared does a better job or is much more updated that the version I obtained. It is clear that the issues come from the Hunspell dictionary. Still some errors, but much less than before. At least now is making "predictable" errors on three character syllables, just like the error in the PDFs you shared. The version used by default on the apps is much much worse. If Affinity is using embedded .dic in the supported languages I suggest to update it, because the results are abysmal. Still not 100% perfect but now I have one or two errors in the current document I'm working on which is "to expect", not 50 or more as before (hunting for autohyphen errors on a 300 page two column document is a torture). So thank you very much! You saved me a lot of precious time in a very loooooong and thick document.

Hi. As far as I understand, for the supported languages, Affinity apps use Hunspell dictionaries (included inside the app). Please, correct me if i'm wrong. Is there any possibility to use the system ones? Because the included Hunspell Spanish (es_ES) dictionary seems to have serious issues on hyphenation, causing a lot on incorrect/forbidden partitions, and we are receiving a lot of corrections from our customers and a lot of time wasted on reviewing documents and manually sorting those errors (which can amount to hours on some long documents). We are not talking about obscure terms not included in dictionary, but pretty basic partitions in very common words, like partition in the middle of syllable, which is a clear NO-No in any language. We have tried to download the last updated dictionaries but those issues persist. We have verified that this only happens within Affinity apps. No other app in our computers makes these hyphenation errors. Also we have checked that this is not a local issue, as all five macs in the studio have the same issue. And yes, we checked to be using Spanish spelling and hypenation languages in Character panel settings. Also, by checking the installation instructions for dictionaries that Affinity offers, it only seems to talk about the .dic file, not mentioning the .aff file if the language offers it. May this be an issue of Affinity not using the .aff information, which includes gramatical instructions complementary to the .dic? Just guessing here.