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

4dimage

Members
  • Posts

    204
  • Joined

  • Last visited

Profile Information

  • Location
    Germany

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Maybe this is just a Problem with my old (outdated) Adobe CS6, Acrobat X Pro Software ? 2024-01-30_afpub_pdf-x3-export-bug_1-1_fail.pdf I tested the failing PDF with an actual version of Qoppa PDF Studio 2023. https://www.qoppa.com/pdfstudio/ There the PDF which fails in my old Acrobat X passes the preflight test. Can anyone confirm this with an actual Version of Acrobat Pro CC (2023 or 2024) ? Does an actual Acrobat Pro CC preflight test the above PDF successfully?
  2. @Andreas CH Super - das ist erst mal eine ordentliche Zwischenlösung für bereits in v2 erstellte Layouts 🙂 Allerdings war auch in v1 und in der aktuellen customer v2 diese Option nie als Teil des PDF/X-3:2003 Presets aktiviert. So sieht das auch in v1.10... schon aus. Es hat also früher schon jahrelang ohne das Umwandeln der Bilder reibungslos funktioniert. Hab mit v1 Dutzende PDF mit flyeralarm unter exakt den Vorgaben ausgetauscht und nie Probleme gehabt. Bis zu Version 2, wo wieder mal Fehler eingeschleppt wurden... Ich glaube die Umwandlung zum Zielfarbraum schon beim Export ist nicht optimal. Zum einen wird gleich mal die Dateigröße der PDF mehr als verdoppelt (RGB zu CMYK), was ja auch übertragen werden muss! Zudem bin ich mit dem RGB-Workflow jahrelang bestens gefahren - es heißt ja nicht umsonst "OutputIntent". Der Druckdienstleister sollte final die Möglichkeit haben, auf Basis der Original RGB-Daten ggf. die Umwandlung zu CMYK auf seine Pipeline hin zu optimieren. Wenn ich die Bitmaps aber bereits nach 300% Deckkraft geplättet habe, gibts da wohl auch final nicht mehr viel zu retten? Zugegebenermaßen dient das exportierte PDF ja dann sowieso nur noch dem Druck bei z.B. flyeralarm. Wie ist eure Erfahrung mit dem RGB-Workflow ?
  3. I did some tests with the actual beta 2.4.0.2256. The weird color profile name bug (ÿISO coated v2 300% (ECI)) seems to be gone. But the final PDF/X-3:2003 incompatibility problem still exists. I tried this basic document setup with a lowres sample image, which is placed in a picture frame: 2024-01-30_afpub_pdf-x3-export-bug_1-1.zip These are the exported PDFs: 2024-01-30_afpub_pdf-x3-export-bug_1-1_ok.pdf 2024-01-30_afpub_pdf-x3-export-bug_1-1_fail.pdf 1) In the first scenario the image fills the picture frame WITHOUT beeing croped. When i export this document with the PDF/X-3:2003 preset everything is ok and the PDF passes the Acrobat preflight check as expected. 2) Exact same document and image -> but in the second scenario i just set the picture frame fill mode to "cover" so that the image is partially croped. When i export this PDF with the same preset, the Acrobat preflight fails: The same error appears as soon as the picture frame is much bigger so that it exceeds the document boundaries and has to be croped during export. My Conclusion: It seems that the error appears as soon as the image has to be croped and resampled during PDF export ? If i just rasterize the layer with the croped picture frame (croped and resampled to document 300dpi) so that the bitmap has NOT to be resampled during PDF export, the result passes the Acrobat preflight. So there might be an issue with pdflib and/or the way the color profile informations are applied to resampled bitmaps during export ?
  4. Bereits mit v2.x erstelltes Dokument mit v1 standardkonform nach PDF/X-3:2003 exportieren Das ist eine Knuschellösung für alle, die glücklicherweise noch die letzte stabile Version v1.10.6.1665 installiert haben. Und weil das scheinbar eh vor allen Dingen die deutsche Version betrifft, spare ich mir hier den üblichen Übersetzungsmarathon. Ich hatte leider das Layout in v2.3.1 bereits erstellt. Für den Druckservice ist eine Beschnittzugabe von umlaufend 5mm vorgegeben - und wie fast überall das Farbprofil "ISO Coated v2 300% (ECI)". Wie bekomme ich nun die korrekten Druckdaten, ohne alles in Publisher v1 neu aufbauen zu müssen ? Kann sein, dass nachfolgend die ein oder andere Option nicht zwingend erforderlich wäre - aber so hat es bei mir am Ende funktioniert. 1) Ich exportiere das Dokument aus v2 komplett oder seitenweise NICHT direkt nach PDF/X-3 sondern mit der Vorgabe "PDF (für Export)". Ziel ist es so viele Eigenschaften der Grafikobjekte wie möglich ins PDF herüber zu retten. So sollen z.B. die eingebundenen Bitmaps nicht heruntergerechnet werden, die Texte als Fonts erhalten bleiben und ich will auch die Beschnittzugabe mit exportieren. Hierzu ändere ich einige Optionen gegenüber der Vorgabe. Vor allen Dingen bette ich sicherheitshalber das ICC-Farbprofil NICHT ein! 2) Ich öffne die alte letzte stabile Publisherversion 1.10.6.1665 und erstelle dort ein neues Dokument mit den identischen Einstellungen, wie das v2.x Dokument. Das bezieht sich auf Größe, Auflösung, Farbmodell, Farbprofil, Anschnitt etc. 3) Ich platziere das aus v2 exportierte PDF in Originalgröße auf meiner Layoutseite. Hierzu erstelle ich einen Bilderrahmen, der sich bis über den Anschnittbereich ersteckt. Hierbei ist zu beachten, dass die Seitenbox-Voreinstellung für platzierte PDF zunächst "BeschnittBox" ist. Das würde zu einem verzerrten Einpassen des PDF in den Bilderrahmen führen. Stattdessen sollte die Seitenbox auf "MedienBox" stehen und der Vollständigkeit halber der PDF-Transfer auf "Interpretieren". Letzteres zeigt dann auch bei nahem Heranzoomen, dass die Texte korrekt exportiert und nicht gerastert wurden. Die Einpassen-Eigenschaften des Bilderrahmens sollten auf "Minimal passend skalieren" stehen. Stimmt alles, so zeigt das Transformieren-Panel beim Selektieren des Bitmap-Inhaltes exakt die Größe des Bildes an, die inklusive Anschnitt erwartet wird. 4) Aus diesem v1 Dokument exportiere ich jetzt mit der Vorgabe "PDF/X-3:2003". Die Option "Inklusive Anschnittbereiche" muss aktiv sein, damit die Beschittzugabe Teil des PDF wird und alle Rahmen korrekt geschrieben werden. Heraus kommt ein standardkonformes PDF/X-3:2003, das in Acrobat den Preflight Check fehlerfrei besteht. Danke Serif, dass ich diese Aufgabe, die normalerweise 1/2 Minute dauern würde, in einer Stunde erledigen durfte. What an amazing tool...
  5. Damned, i ran into this crap one more time. Stil trusting in Publisher v2 (2.3.1), i did some signage layouts. How could I have been so stupid? Of course, when exporting it to PDF/X-3 for an online print service i got the same color profile errors. The preflight check in Acrobat fails. This error also appears when exporting from beta v2.4.0.2240. Unfortunately there is no backward compatibility with Publisher v1.10.6.1665 😒 But i don't want to recreate the whole layout in v1.10.x again... 😶 Hi guys - the first post in this thread is of Novemer 2023. Meanwhile any plans to fix this heavy bug ?! Or should I give up my job as a graphic designer and work as a delivery boy instead? All I need is two healthy feet, which thank God I still have. Nothing against delivery workers - they do an honest, hard job! By the way: this error appears even with a fresh EMPTY document. Of course this passes the preflight check because there is no offending content in it. test1.afpubtest1.pdf
  6. I just found the same bug with iso-coated-v2-300 when exporting for an online print service. - Publisher (all) v.2.3.0, German version, Windows 10 This is how it looks like in v2.3.0 and preflight test with Acrobat X Pro (Same profile name error in actual Acrobat Reader): BUT: the preflight fails not only with iso coated v2 300% (ECI) profile but e.g. also with coated fogra39: ----------------------------------- To verify that this is not a Windows color profile error on my computer, i set up the same document layout in Publisher 1.10.6.1665: This shows the correct color profile name in ACrobat X Pro and passed the preflight like a charm: So again - after more than one year of v2 i have to switch back to v1 to get my daily job done. This should be a simple PDF export but now again i spent over 1.5 hours to check the bug and document it. This is so annoying 😔
  7. Hi, as reported here: As feared, some bugs that where already logged in the Windows version in the beta were not fixed in the "stable" release v2.2.0. When I see the advertisement for the new release on the Serif website, the MAC dialog seems to be shown there. This also looks like it's working properly. Can any MAC user confirm this ? I increasingly have the feeling that some UX errors and weaknesses will be fixed for the MAC/iPad version with high priority and then in the end there will be no time left to implement them identically in the Windows version ?! And this is how the bugs in the current v2.2.0 Windows release still look like: Flipping form groups, missing/different translation, wrong button labels ?!?! 2023-09-19_publisher-windows-custom-fields-bugs-not-fixed.mp4 Not funny...
  8. Now there are two form groups. One with "Custom", one with "Selbst definiert". The latter appears after creating the first custom field: Furthermore the two groups flip panel position after deleting at least one custom fields: 2023-09-04_2.2.0.1986-beta_fields-panel-double-group.mp4 After deleting all custom fields the "german" group disappears and now the tooltip for the plus-button has a wrong label:
  9. Hi Gabe, Don't know, where to post these old Bugs. I'm "sorry" if I "annoy" anyone. I spent hours and days of testing and bug reporting during the last 12 Month since release v2. For good reason. In plain language: Either, I'm just moaning around. Or I try to help make the software better. I decided to do the latter after the first big disappointment with v2. We, who have to work with the software every day, have little choice but to help find the bugs and describe them in a way that is as reproducible as possible. All in the hope that they will be fixed as soon as possible. Until then we have to work for hours every day with the workarounds! So, in exchange for my time and the time and effort of many other beta testers and dedicated users, I think it's appropriate to also point out some old bugs that I think are absolutely important to fix, but don't seem worth the trouble are to be fixed with priority ? Instead, new features are still being added instead of making version 2.x completely stable at least once. I'm talking about the basic functions here. And slices are an absolutely important and fundamental functionality for my work. Feel free to move this post to wherever you want the seemingly irrelevant trash to go...
  10. Hi guys, as already mentioned the slices panel presets are still not working. Switching preset produces random form output. The upper preset select and the other form controls have to be properly synchronized. This applies to both the standard tab and the selection tab. Some of the old presets (v1.x) behave as expected. The newer ones (webp, jpeg xl) and others behave randomly. I have to use the slices in every web project. For web development this is not a nice to have. It's a fundamental functionality like exporting PDF-X for print. Not seeing a clear slice status is very annoying and completely unproductive. You can't select a clearly defined standard preset for new slices and have to fiddle around each time you create a new slice. In addition, if you don't see the preset name in the upper select it is not possible to delete a custom preset without a doubt. And - this all worked fine in v1 🙄 The standard tab: 2023-08-16_2.2.0.1954-beta_slices-panel-mess_001.mp4 The selection tab: 2023-08-16_2.2.0.1954-beta_slices-panel-mess_002.mp4 By the way. For me the slices export to SVG, WebP,... is the number one reason why the Affinity apps provide an almost perfect toolset for web development. Layout pixel perfect in Publisher | Designer | Photo -> open in Designer -> create slices from any piece of your artwork -> export web ready graphics as bitmap and/or vector in multiple resolutions and sizes 👍
  11. 1) Thanks😁 The refined Windows panel appearence looks so much clearer now 👍 The Windows issue with the truncated labels still exists. The panel persists the column width of the left label-column at least during one user session. But after app restart the column width is reset to default and the labels are truncated again. In consequence the user has to resize the column once for every user session to read the truncated parameter names. Would be helpfull, if the last user defined column width could also be persisted like the panel size. 2) I can't rename a custom field - maybe this is intended behaviour ? Steps: a) I add a custom field to the palette with some inital value (German translation missing). OK so far. b) Now i edit the field by clicking the button "Edit Custom Field" (German translation missing). The flyout dialog shows the text input with the current field name selected. It appears as if i could change the name. But as soon as i press any letter key the flyout dialog closes without letting me type into the input. If the field name may not be changed afterwards, the input might be disabled to indicate that the name is immutable ?
  12. Sean, you are right! A quick zoom change updates the viewport and all text frames are rerendered correctly. So, the devs can easily fix this 😁 2023-07-18-publisher-windows-fields-update-002.mp4
  13. It's a little bit confusing. The update error seems to occur as soon as i select the second (bottom) text frame. Either select the second text frame Object as a whole or setting the text cursor inside the frame. 2023-07-18-publisher-windows-fileds-update-001.mp4 The internal IDs in the layer preview look the same ?
  14. I can't reproduce this focus problem on Windows. It seems that the input focus remains in the text frame after inserting a custom field by doubleclicking in the fields panel (as intended). Sorry for having no visual mouse-action marker in the video. I don't click into the text frame inbetween. The cursor stays active in the text so i can type the next letter directly after inserting the field by doubleclicking in the panel. This also applies when the panel is docked in the UI. But another bug: at the end, after changing the field value in the panel, only the second text frame is updated. 2023-07-18-publisher-windows-fields-focus-001.mp4
  15. Yes it does. Here is the complete show: 2023-07-15-publisher-fields-panel-custom-field-bug-002.mp4
×
×
  • 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.