Jump to content
You must now use your email address to sign in [click for more info] ×

Daniel Gibert

Members
  • Posts

    309
  • Joined

  • Last visited

Posts posted by Daniel Gibert

  1. 2 minutes ago, MikeTO said:

    Just to confirm because I know some people didn't manually copy their settings over from v1 and thus things are working a bit differently for them, you do have "Automatically update linked resources when modified externally" checked in Preferences > General, right? I don't see how having that unchecked would cause the problem you're having though.

    Yep. The setting is active (And even tried to deactivate/restart/reactivate it/restart again, No result. We didn't used v1 settings, preferred to set new ones by hand.

    Gonna try to deactivate 3rd party apps and extensions to see if there is an issue with other software interfering. I'll let you know as I study it.

     

  2. Hi. Publisher is not updating the external PDFs or Designer. files after being modified. The settings are correctly set to do so.

    Also, it does not show the "Update" option on the Resource manager.

    The external files are set to "Linked"

    The worst thing, is that if you save the publisher document without updating the image, you cannot reopen it again, receiving a message that the file contains characteristics from a former version of Publisher ???????

    1714150422_Capturadepantalla2022-11-13alas15_00_16.png.f0348f2157354d4e9afd646e28acc665.png

    Procedure:

    • Create a figure in Designer 2 and export as PDF (X1A)
    • Import the figure to Publisher (Linked)
    • Modify the figure on Designer and export again replacing.
    • The figure never gets updated on Publisher, nor the option to manually update appears.
    • Save the document without updating the linked image. It fails at reopening it.

    I tried with PNG and JPG and it detects the changes perfectly.

    Tried in a second Mac, and it fails to update too (Although it says that the image has changed, just not updating the preview) and crash trying to reload the image. Seriously something is wrong with placed vector files or the preview interpreter.

    Publisher becomes totally unusable to me, as I can't risk to damage any of the works I have in progress, all of them using imported PDFs and linked Designer files. Literally, I can't work with Publisher 2 just now. It is an incredible risk, which could cost me thousands on damaged and undelivered works. I'll remain in v1 at this moment.

    Added info:

    Tested with 2 computers, one with files in external SSD and other with internal drive, both fails. Both with Ventura 13.0.1

    Attached you have an example of a document corrupted.

    broken file.afpub

  3. Hi there.

    When using v2 apps (All suite) Stage Manager on ventura moves very awkwardly, like dropping frames. It only happens with the V2 apps. V1 and the rest of the apps in Mac working fine.

    Between other apps, even with v2 open, is smooth as silk. Is just when opening and closing v2 apps when it happens.

    The "chunkyness" vary, sometimes is just chunky, other times is like watching netflix with bad wanwidth

    Mac Mini m1
    16 gb ram
    Ventura 13.0.1

     

     

     

  4. 15 minutes ago, Alfred said:

    In that case (sorry!) can’t you work around the issue by converting from uppercase to lowercase first? :/

     

    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.

  5. 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.

  6. 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? O.o

    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 :P)

    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!

  7. 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)

  8. 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

  9. 10 hours ago, garrettm30 said:

    Actually, if you click on the link in the post above this one, you will find an interesting paragraph, accompanied by a preview image.

    So it looks like some sort of Books Panel is expected to happen at some point. We just don't know when.

    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…

  10. On 2/3/2022 at 3:02 PM, Dan C said:

    Hi @Daniel Gibert,

    Thanks for your report!

    I believe the application is behaving as expected here - the image files you have placed are RGB, in a CMYK document. When exporting to an RGB PDF, the adjustments are applied to the image after the colour conversion. Meaning your RGB images are converted to CMYK in the app for preview, then 'unconverted' (so to speak) when you export to RGB PDF. 

    The same results can be seen if you copy and paste the image layer from your CMYK document to an RGB document - with your adjustment at 200% value, the image is blown out in RGB -

    image.png

    I hope this clears things up :)

    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.

  11. 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

  12. 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.

  13. 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

     

  14. 3 hours ago, Pedrober said:

    Please verify if you are using this version of the hunspell hyphenation file, located at \Users\~\Library\Spelling\es-ES.

    hyph_es_ES.dic 5.45 kB · 1 download

    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.

  15. 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.

  16. Hi. I'm uploading a video capture so at Affinity they can understand better the issue, and how i'm getting rid of it (And you can too, probably).

    Please, note that the solution of clicking the clear format icon does not solve the issue, simply correct it in an easy way. The bug that make the TOC styles going bananas continues to be there. (That is, updating the TOC adds extra format modifications to the TOC styles)

    Also note, be sure to have the Character and Paragraph Styles set to [no style] before updating the TOC to minimize the amount of trash added after updating. I have been solving this issue with this method but i'd love to not having to do.

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.