Jump to content

Mooxo

Members
  • Content Count

    13
  • Joined

  • Last visited

  1. Okay, thanks. As I say, I was able to export it okay from 1.9.0 so it was more about logging the bug.
  2. Did you receive the files? I sent them on Monday.
  3. I tried a couple of PDF presets but it was the same. Only rasterizing worked for PDF export. I was able to export problematic pages as PNG, although that was only for testing. I can’t find an upload link in your post? I’d rather not upload to the forum. Is there a dropbox link I can send them to?
  4. This beta has fixed the file opening bug that I reported in the Bugs forum. However, both this beta and the previous one are causing me problems with PDF export... Mac OS Catalina 10.15.5 running on a Macbook Air (model id 6,1). No external devices other than permanently attached SSD. My problematic document is 209 pages, imported from IDML, reformatted, and saved as regular afpub. Other documents I have tried have worked ok. When I try to export to PDF I get an error: “An error occurred while exporting to: <filename>”. The error happens wherever I try to export the file on the system, be it local drive or icloud. I can export pages 1-21 without problem. Any page from 22 onwards that I try fails. Exporting 1-22 fails. Exporting 22 or 23 on its own fails, etc. There is nothing I can see that is different about pages 22 and on — they are a continuation of the same text flow using the same master pages, fonts, etc. Preflight shows only spelling warnings. If I set it to export text as curves, the error remains. If I set it to disable advanced features, the error remains. The only way I can get it to export is to set it to ‘rasterize everything’ (though this makes an unacceptably large file). I have done the PDF logging thing and the error at the end of the file reads: [Last exception 1113 in PDF_rect]["Number parameter 'y' has bad value '-215723171361689126693305940258774955854831264025790984366933353005963925736340364766740324843394693930763637765777116666640215904422765062065054010734467522159667853218497575660516896304869827726833649588347945387400948462600982054168988953002738186639960' (maybe not initialized)"] I’ve no idea if that’s useful. I’m happy to provide the log file and the document, if it helps. NOTE: This only affects the beta version. If I open the file in the non-beta 1.9 release, the export works perfectly.
  5. I just wanted to update this thread to say that the most recent beta (1.9.1.967) has fixed the problem for me — I’m now able to open both the files that were crashing before. Thank you! The beta has introduced a new bug for me, but I’ll post that in the beta thread (pdf export related).
  6. Thanks for that. I’ve downloaded the beta, and am now able to open one of the files (the second one I uploaded). The other one still crashes the application though.
  7. Mac OS Catalina 10.15.5 Publisher 1.9.0 (Affinity store version) When I try to open two recent files, Publisher is crashing. One of the files was created in 1.9 and the other in 1.8.6. The files opened fine yesterday, and have not been modified since. File size does not seem to be a problem as I can open other files that are larger that those which are crashing. The app crashes whether I open the files by double-clicking in the Finder, or opening them through the File...Open menu. I have tried rebooting the machine. I have tried opening Publisher with CTRL held down and the first three options on the reset list checked. No external monitors etc, just a USB SSD drive that’s permanently attached. I’ve attached two crash reports because they show different exception types (I’ve no idea if this is important). Happy to provide a crash-inducing file if it helps. publisher-crash-report-10221-1-mooxo.txt publisher-crash-report-10221-2-mooxo.txt
  8. I have finally found the difference between the working tiles and the non-working ones. If a tiled image is rotated, even just a tiny bit, it renders as a PDF correctly. If it is not rotated, it will not render correctly in PDF. Resizing makes no difference, it's only the lack of rotation that stops it working properly. I can reproduce this bug every time: 1. Create a blank document. 2. Place a frame the that fills the page to the margins. 3. Use the fill tool to fill it with a tiled image. Don't rotate it. 4. Output as PDF. It won't render correctly. Output as jpeg, it will render correctly. 5. Rotate the tiled image a bit, try outputting as PDF again and it will output correctly. 6. Put the tiled image back straight, and it will no longer output correctly as a PDF. Hope this is useful in fixing the bug. A possible workaround in the meantime is to "pre-rotate" an image destined to be used as a tile fill, then rotate it back in Publisher to get it straight again.
  9. A couple of other things I've tried: Using the default blank master page and recreating the tiled fill directly on the spread. Creating a brand new document from scratch and making new master pages with tiled fills then applying them to blank pages. Same thing, won't output correctly as PDF. I can't help feeling I'm missing something obvious here. This seems like a pretty basic thing that should work.
  10. Is the Resource Manager window in Publisher supposed to list all the resources in a document? Reading the manual that's what it sounds like. In one of my documents it's only showing images from six pages out of 70. Is this normal? Version 1.7.3 on a Mac.
  11. I have a problem with a document because some tiled bitmap fills are not rendering correctly when output as PDF. I believe, given this thread, that this is a known bug. As there’s been no further reply over on that thread, I’ve done some more testing. Here’s what I’ve found so far: I have eleven master pages each using a frame filled with a tiled bitmap. Of these, only four render correctly when output as PDF (using any of the presets). If I export a spread with a non-working master page as jpeg, it renders correctly. (This is not a workaround as I can’t send jpegs to the printer.) If I use a working master in place of a non-working master, the same page then renders correctly. That suggests it's not the spread that's the problem, it's the master page. If I duplicate a working master and use that, it renders correctly. If I then replace the image in the duplicated master with a different one, it no longer renders correctly. If I go back and put back the original image, which was working, it then no longer renders correctly. Therefore it appears it’s not the image I’m tiling that is the source of the problem. If I create a brand new master page from scratch, it does not render correctly, even if I use an image that is working in another master page. The problem is exactly the same whether I output the entire document or just an affected spread. Right now I’ve got a 70-page document I can't publish because about 20 pages of it won't output correctly as PDF no matter what I try. If anyone has any suggestions for workarounds or other things to try, I’d love to hear them, thanks. I’m running Publisher 1.7.3 on a Mac.
  12. Any new on this being fixed? I’ve just completed a 70 page document, am on a deadline for publication, and have run into this bug. Almost every page uses a master page with a border made with a bitmap fill, and about a third of them just don’t render. They include one instance of the bitmap rather than tiling it. Works fine if I export a spread as JPEG, but none of the PDF formats work. I’m running whatever the latest version is on a Mac.
×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | 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.