Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by 4dimage

  1. Hi, unfortunately the error doesn't occur again completely in the manner described above (restarted my computer several times since then). Neither with the complex tall document (see above) nor with a new document (simple landscape fullhd). error 1) At a second glance i saw in my screenshots that the document/rulers weren't fliped (vertically mirrored) but rotated by 180 degrees. So there might be an unintended interference with the publisher function view -> rotate left/right ? This error does not show up again. So i could not do further tests on this. error 2) The other part of the described behaviour stil shows up. After hiding all publisher windows via shortcut WINDOWS + D and returning back from the Windows Desktop with WINDOWS + D (toggle), the view in the second display shows an empty window. No rulers, no layout pages. Only the standard window title (programm icon + doc title) AND the publisher footer control bar (pages, tool context info, ...). To get any contents back into view on the second display i have to either minimize the program window there or focus this window via the Windows taskbar button. Further tests show this interesting point: The error 2) only appears when the programm window in display 2 is maximized! If the window in display 2 is not maximized when switching to the Windows Desktop and back again, the window will immediately show up correct. Even with the shortcut WINDOWS + D. As soon as i maximize the window again the error 2) occurs again. I can reproduce this with new publisher views or the same views several times by switching from maximzed to non maximized state. So the window maximze state is part of the problem in combination with my 2 display windows setup ? Here are my Windows display settings. The second display (left hand 2 ) has a smaller resolution:
  2. Hi Gabe, this might be an expected behaviour from a developers point of view. But i guess this behaviour is counter intuitive because the master symbol can be moved like any other object in the layout page. So why should it behave in a different way when it comes to layout scale? When i set the transform origin to the upper left corner and layout fix method (in german: "Auf Seite verankern") activated i expect that all elements in the layout stay unscaled at their orginal position - including the master page symbol. Only the layout page boundaries should resize to right/bottom. And mind the impact on my daily work (screendesign - not print). I have to export dozens of screenshot JPG/PNG for customer approval. Almost after every context change in a layout page (new text, additional images, ...) i need to change the page height. This is because i don't want to have a huge blank space at the bottom of a screenshot. A customer might think this is an intended part of the screendesign ! As a consequence i always have to correct the page height so that the screenshot shows a realistic webdesign from header to footer. Now count the seconds and minutes per day only to fix the master layout shift by always manually repositioning the master symbol to the upper page border again. Sorry - but these endless workarounds are really time consuming...
  3. Hi Gabe, here is a simple test file which reproduces the behaviour: bug-demo_layout-scale_master-page-shift_1-1.afpub The master symbol in the layout page is always shifted to the vertical center of the layout page although the scale method (transform anchor) is relative to the upper left corner. By the way: it's so annoying during every day work to always have to unlock proportional scale and set the anchor again every time one opens this layout scale dialog again. Why not at least remembering the last used settings ? To my mind there is little use of scaling the contents of a layout page together with the new page height because this will distort the layout content. In most cases this is not the intended behaviour (unless the new page size is proportionaly scaled up or down, e.g. from one DIN format to another). As far as my work is concerned in almost all cases i need to extend the layout page height to add more page content at the bottom. My workflow is as follows:
  4. Publisher Version System is Windows 10 with latest updates, runing a NVIDIA Quadro P4000 with driver version 431.94. The second display is set to the left side (Windows Settings -> Display: Monitor 2, left hand). Hi, i opened a new view of the same Publisher document and undock / move the window to a second display. I maximize the program window (standard upper right corner icon, window maximize) to fill the second display fullscreen. So far so good - nice feature ­čÖé 1a) After changing to the Windows Desktop (WINDOWS + D, all Publisher App Windows hidden) and returning to Publisher the window on the second display show all layout pages upside down. Even the rulers / coordinate origin is fliped ! I verified this by creating a third view of the same document and also undocked it and move it to the second display. This 3rd view also shows it's content and rulers upside down. 1b) After bringing the Publisher window to front on the second display the view does not show any layout pages. No view zoom shortcut will bring any layout page into view. Even doubleclicking on a layout page icon in the page-palette will not bring any page into view on the second display. The only way to show a layout page again in this second window is to minimize the window (no longer fullscreen). But, as mentioned in 1a) the view then shows the pages / rulers upside down. When checking the layout pages in the main display (Windows Monitor one) the layout page is intact and not fliped. So this might be an open GL error ? If i minimize the second window and dock it again into the main Publisher layout window (now 2 Tabs docked into the Publisher main window) the false view flips and now shows the correct orientation again. These errors always occur when hiding/showing (toggle to Desktop and back again) the Publisher Windows via WINDOWS + D shortcut. 2) Another way to fix the empty view in the second display is, to explicitly focus the second window via the window icon in the Windows Taskbar. Then the window content ist restored immediately in the correct orientation.
  5. Hallo elk, ja ich k├Ąmpfe seit ├╝ber 2 Jahren st├Ąndig mit den Affinity Programmen, da ich auf jeden Fall nicht in dem erpresserischen Adobe CS Mietmodell enden will. Und die 3 Affinity Programme sind, wie Du schon sagtest, auch f├╝r mich die einzige professionelle Alternative zu den Adobe Hauptanwendungen Photoshop, Illustrator, InDesign. Ich habe im Markt nichts vergleichbar Modernes und gut Ausgebautes gefunden (Corel Draw und Konsorten sind ziemlicher Krampf, QuarkExpress nat├╝rlich absolut professionell aber irgend wie strange UX). Gerade Affinity Publisher ist mit InDesign CS6 verglichen echt der Hammer ­čÖé Und Affinity Designer z.B. als PDF / EPS / AI Dosen├Âffner ist ziemlich krass... Ich mach das Adobe Spiel jetzt schon seit ├╝ber 25 Jahren mit (Aldus gekauft, Macromedia gekillt, ...). Dabei war f├╝r mich Photoshop schon immer das Arbeitspferd schlechthin - und wird es wohl auch noch eine Zeit lang bleiben m├╝ssen, bis die Affinity Suite so geschmeidig l├Ąuft wie die Adobe Dinger (da wimmelte es aber auch ├╝ber die Jahre immer wieder mal von Bugs). Aber Adobe hatte auch ├╝ber 20 Jahre gebraucht, um durch das User-Feedback alle professionellen Funktionen stabil auszubauen. Also ist Geduld mit Serif gefragt - auch wenn es manchmal schwer f├Ąllt
  6. THE REASON ok, i guess i got it. Publisher seems to manage the master page contents as symbols in the background layer of each layout page. After scaling the layout page from the upper left corner with fixed content method, the other content elements in the layout page are neither scaled nor moved. That's how i expect it to work. Nonetheless the master symbol IS moved downwards in this case. And the guides contained in the master symbol of course move with it: After moving the master symbol to the upper layout border the contained guides move with it in the expected position: This workaround works but is not really self-explanatory. After all the master symbol is a content element like all others on the layout page - isn't it ?
  7. Publisher Windows, Version Hi, i use publisher the most time for webdesign. This means i typicaly prepare some master pages for the common viewport widths, e.g. fullhd, tablet, mobile, ... When designing the content pages i have to scale the layout pages to different heights, to filll them with demo content. E.g. a layout page that shows mobile content will be a very long "strip" which is 360px wide, but 3000px in height. Every content page has an individual height depending on the demo content in it. This height changes always during the design process. But of course typical page items like header bar with logo and navigation elements are part of the respected master pages. PROBLEM Together with typical design elements that appear on every content page (e.g. header bar) i set some guides in the matser page to see typical heights in the layout pages that relay on this master page. This might be 2 guides which set the the max height of a page hero or something else. What i expect is, that the quides from the master page always remain at their original position when scaling a layout page relative to the upper left corner. The Elements in the layout page should NOT be resized. I only need more height to add additional content at the bottom of the layout page. But, after scaling the layout page using these settings the giudes that derive from the master page are shifted verticaly in the layout page. I set the transform origin to the upper left corner. But this doesn't work as expected. Instead it becomes more weird, when using the other layout scale method. Then the guides from the master stay intact but of course the whole content of the layout page is scaled unproportionaly. This is of course nothing that anybody needs ­čś×
  8. Hey, danke Joachim - das ist auf jeden Fall eine Arbeitserleichterung :)) Ich hatte die beiden Zusatzoption im Dropdown ├╝berhaupt nicht bemerkt, da ich dachte, hier geht es immer nur um die Dokumentseiten. Die tauchen ja auch erst auf, wenn man in dem Moment tats├Ąchlich ein Objekt markiert hat. W├Ąre vielleicht hilfreich, die immer anzuzeigen, aber ggf. inaktiv/ausgegraut ?! Somit kriege ich zumindest schon mal die typischen Heros und Beistellbilder aus dem Layout raus - leider nur mit 72 dpi. Scheinbar ist der Export unabh├Ąngig von der eingestellten Dokument-Aufl├Âsung. Also dort 300dpi einzustellen bringt nix. Das Resultat bleibt 72dpi. Oder hab ich da noch was ├╝bersehen ? Z.B. Logos und andere Strichgrafiken, die ich mit 2x oder 3x Aufl├Âsung f├╝r das Webdesign br├Ąuchte muss ich also nachwievor in AD ├╝ber slices exportieren. Na ja, hoffen wir mal auf Publisher 2.0 NACHTRAG ok, ich hab einen Workaround. Im Export-Dialog setze ich manuell die Pixelgr├Â├če z.B. auf den doppelten oder dreifachen Wert. So skaliert z.B. die Logografik beim Export zu PNG proportional und ich habe 2x oder 3x Aufl├Âsung. Ist nat├╝rlich auch alles zeitaufw├Ąndiger, da jede Grafik einzeln behandelt werden muss. Da sind Slices nat├╝rlich praktischer, wenn man bei Korrekturen Objekte immer mal wieder neu exportieren muss. Es bleibt schwierig
  9. Hi guys, thanks for your efforts ­čÖé Take care everybody!
  10. That's interesting. Then the effects (unsharp mask) are not cliped by the picture frame boundaries. Hope you can fix this :-)
  11. Hi Walt, here are the settings in Designer, the same as in Publisher: And these are the document and snap setting: To my mind, setting the Pixel digit to 1 is more than enough. To be honest, I hardly never use float positions or dimensions when working for webdesign (force fulll pixels at 72dpi document resolution). And mostly I type in the values in the transform panel to be exact. I don't think that's the reason for the slice problem. And if it would be so - think of the consequences. This would be a serious overall bug! No matter what's internaly calculated (float), the transform panel MUST always show the real status of the selected object/s so I can rely on this. If it shows an integer it has to be an integer. If not, the transform panel has to show a float value. Otherwise the transform panel would be worth nothing ?!
  12. Hi Sean, document is uploaded to dropbox. Good luck By the way - the collect option in 1.8 will be a great helper :-)
  13. Hi Sean, this is a customer project with some big JPGs linked from a network drive. Would it be OK if I upload only the Publisher document itself - without the image files ? Don't know how to pack it into one zip without relinking the images ?!
  14. AD version Hi, I have to create slices from a weblayout to export jpgs. In this case i have picture frames with linked images in a Publisher document, which are exactly positioned/sized on integer pixel values. To export the images for web, i open the Publisher document in Designer and switch to export persona. My typical approach is to select the orginal object in the layers panel and create a new slice by pressing the "new slice (Slice erstellen)" button at the bottom of the layers panel. Example: the object is 480 x 480 px at position 0 / 1850 px. Normally when i create a slice from a selected object the slice directly takes the object/layer name and the EXACT dimensions and position of the original object. Even if i select multiple objects/layers and create all slices in a single shot. But in this case all created slices are some pixels bigger and shifted off. e.g. the created slice from this object is 482 x 482 px at position -1 / 1849 px I have some other big header images in this document at position 0 / 0 px with 1920 x 1080 px. These images produce slices with exact the original values as expected. So what's wrong? Is it because this is originaly a Publisher document, or is it about the picture frames? Unfortunately the slice tool does not snap to any grid or guides, so i have to manually correct all slices in the transform panel. Lot of workarounds and lost time - again... :-(
  15. Hallo, sorry hierf├╝r - aber gerade frustriert mich die Arbeit mit Affinity Publisher (Studio) mal wieder derart, dass ich meinem Frust mal wieder hier raus lassen muss. Und weil ich es auch leid bin, technisch schwierige Sachverhalte stundenlang unter Zurhilfenahme von ├ťbersetzungsprogrammen notd├╝rftig in Englisch zu beschreiben - hier das ganze auf Deutsch. Vorweg: wie schon ├Âfters hier im Forum beschrieben, finde ich einige Features der 3 Affinity Programme richtig klasse! Aber, wenn man dann mal in die praktische Arbeit geht, sind es dutzende Kleinigkeiten, die einem den Spa├č an der Arbeit mehr oder minder vermiesen. Ich muss damit mein Geld verdienen und habe keine Zeit f├╝r st├Ąndige Workarounds, nur weil irgend ein Werkzeug mal wieder nicht richtig funktioniert. Der aktuelle Fall ist wieder mal ein Webdesign: (Beachte die Hilfslinien und Spaltenhilfslinien) Da es in Designer LEIDER immer noch keine M├Âglichkeit gibt, Bilder resourcenschonend hinzuzulinken statt sie einzubetten (immer noch keine Resourcenverwaltung), verwende ich mittlerweile Publisher f├╝r das Layout. Und das geht mit Publisher auch f├╝r Webdesigns richtig gut :-) Die im Screenshot zu sehende Publisher Datei ist nur ca. 6 MB gro├č, obwohl sie 26 verkn├╝pfte JPG enth├Ąlt. Genau so soll das sein :-) Was in Publisher beim Designprozess zudem auch richtig praktisch ist, ist die M├Âglichkeit alle visuellen Hilfen (Hilfslininen, Spalten, Rahmen, ...) mit einem Tastenk├╝rzel auszublenden "Ansicht -> Vorschaumodus". So kann man st├Ąndig schnell das Design in Originalgr├Â├če begutachten (verl. InDesign). F├╝nf Sterne daf├╝r Das Handling der Textformate, gerade zur Simulation von Headings und Listen, ist auch in Publisher irgendwie fl├╝ssiger, als in Designer ?! Sehr praktisch ist z.B. auch die M├Âglichkeit schneller Bildkorrekturen (die unvermeidliche Tonwertkorrektur, Nachsch├Ąrfen etc.) direkt in Publisher -> Photo Persona :-) Also ist Publisher erstaunlich gut f├╝r Webdesigns zu gebrauchen - auch wenn es vielleicht nicht prim├Ąr daf├╝r gedacht war ?! So weit, so gut Bis zu dem Zeitpunkt, wo das Webdesign nun in seine Einzelteile zerlegt und programatisch mit HTML und CSS umgesetzt werden muss. Wie kriege ich die Fotos f├╝r Web optimiert aus Publisher heraus? Variante 1) In Designer w├╝rde ich in das "Export Persona" wechseln und diverse Slices mit den gew├╝nschten Exporteinstellungen setzen. Diese Option steht mir in Publisher -> "Designer Persona" aber nicht zur Verf├╝gung. Oder bin ich zu bl├Âd, die Option zu finden? Das ├ľffnen der Publisher Datei in Designer ist zwar m├Âglich, aber f├╝hrte bei mir schon mehrfach zu totalen Programmabst├╝rzen und ein Mal sogar zu Datenverlust. Auch werden die Slices zwar in Designer irgendwie in dem Dokument gespeichert, k├Ânnen aber bei mehrfach wechselndem Speichern in Publisher und Designer verloren gehen ?! Das ist mir momentan wirklich zu heikel. Wie gesagt, ich habe keine Zeit f├╝r st├Ąndige workarounds. Ich muss meine Projekte fertig kriegen. Variante 2) Ich wechsle in Publisher in das "Photo Persona" und markiere mittels dem Werkzeug "Auswahlrahmen - Rechteck" jeweils einen Bildbereich und hole ihn ├╝ber "Bearbeiten -> Reduziert kopieren" in die Zwischenablage. Dann wechsle ich zu Photoshop (!) erzeuge das neue Bild aus der Zwischenablage und exportiere es ├╝ber "F├╝r Web speichern (CS6)" zur Weiterverwendung in der Webprogrammierung. Und jetzt kommt wieder der scheinbar unvermeidliche Affinity Detail-Fallstrick. Ich arbeite nie nach Augenmass sondern immer pixelgenau. Leider mangelt es aber beim Photo-Rechteckauswahlwerzeug an Pr├Ązision. Wie kann es sein, dass ich es schaffe, bei gehaltener SHIFT-Taste durch Ziehen des Cursors ein NICHT quadratische Auswahl zu erzeugen??? Ein Quadrat ist immer ein Quadrat - auch wenn es rechnerische Rundungsfehler gibt. Das hier sind die aktuellen Snapping Einstellungen in dem Publisher-Dokument: Schon schlimm genug, dass sich das Werkzeug am Dokumentrand nicht pr├Ązise ausrichtet (Ich schaffe es zudem nicht, dort eine Hilfslinie zu platzieren). Auch richtet sich das Werkzeug beim Ziehen nicht an den anderen Hilfslinien aus. Das bedeutet, der gesamte Auswahlprozess ist wieder mal ein Gl├╝cksspiel. Ich versuche dann in der Transformieren-Palette den ├ťberblick zu behalten. Aber das ist doch manuelle Knuschelei, die unn├Âtig Zeit beansprucht. Hilfslinien sind schlie├člich daf├╝r da, dass sich die Werkzeuge schnell und pr├Ązise an ihnen ausrichten. Mannomann - ich will nur einen pr├Ązisen Auswahlbereich erstellen. Das sind absolute Basics, um die ich mir eigentlich ├╝berhaupt keine Gedanken machen will. Wie gesagt, habe ich schon genug Zeit damit verschwendet, die Bilder durch Aussschneiden und Photoshop Nachbearbeitung aus meinem Design heraus zu bekommen. Variante 3) Ich speichere das gesamte Seitenlayout als TIFF mit verlustfreier Kompression, ├Âffne es in Photoshop und schneide dort die Bilder heraus und exportiere sie f├╝r Web. NACHTRAG: auch hier lauert die Falle im Detail. F├╝r den Export als Bitmap wendet Publisher eine Interpolation der gerasterten Bildrahmen an. Dabei werden - trotz exakt auf genaue Pixel positionierten Grafikrahmen (laut Transformieren Palette exakte Positionswerte x/y und Breite/H├Âhe), viele R├Ąnder der Bildrahmen durch die Interpolation weichgezeichnet. D.h. ein vorher scharfes Rechteck hat z.B. links und rechts jetzt eine 1px weiche Kante. Also ist dann ein Ausschneiden aus dem exportierten TIFF wieder nicht fehlerfrei m├Âglich. Also habe ich am Ende doch die Publisher Datei in Designer ge├Âffnet und die betroffenen Bildrahmen ├╝ber Slices nach JPG exportiert. Und Designer ist trotz der hinzugelinkten Bilder dabei auch nicht abgest├╝tzt... Herzlichen Gl├╝ckwunsch... In einer idealen Welt: - Sch├Ân w├Ąre, wenn es in Publisher -> "Designer Persona" irgendwie m├Âglich w├Ąre, den Slice-Mechanismus/Export verf├╝gbar zu machen. Dann k├Ânnte man das Exportiern der Bilder f├╝r Web direkt in Publisher erledigen. Das w├Ąre sicher nicht nur f├╝r Webdesign hilfreich. - Das resourcenschonende Hinzulinken (nicht Einbetten) von externen Bitmaps sollte auch in Designer so m├Âglich sein, wie es schon in Publisher funktioniert. Das h├Ąlt die Dokumentgr├Â├če wie gew├╝nscht sehr klein. Dann k├Ânnte man auch Designer wirklich praktisch f├╝r Webdesigns verwenden. - A propos Resoucenverwaltung: warum wird die zuletzt genutzte Gr├Â├če des Dialoges "Dokument -> Resoucen verwalten" nicht gespeichert ? Jedes Mal beim erneuten ├ľffnen des Dialoges muss man wieder das Fenster gro├č ziehen und nach unten scrollen. Das sind immer Sekunden, die sich zu Minuten addieren, die verschwendete Arbeitszeit sind. Genaugenommen, sollte die gesamte Funktion in einer schwebende Palette verf├╝gbar sein. Das ist keine "Nettigkeit", sondern eine Kernfunktion von Publisher (vergl. InDesign). - Das Snapping von Werkzeugen und das Handling von Hilfslinien sollte "schmerzfrei" funktionieren. - und Dutzende weiterer Stolpersteine, f├╝r deren exakte M├Ąngelbeschreibung ich momentan hier keine Zeit habe, die aber unn├Âtig Arbeitszeit verschwenden (z.B.: direktes Anzeigen meiner document Farbpalette beim erneuten ├ľffnen, globale Farben in Farbverl├Ąufen erfordert multiple Mausklicks, umst├Ąndliches Umbenennen / ├ändern von globalen Farben, kein Update von globalen Farben in Farbverl├Ąufen ?!, Das Handling von Farbverl├Ąufen insgesamt - das geh├Ârt in eine schwebende Palette, Auslesen von Farben aus Farbverl├Ąufen beim ├ťbertrag in CSS Programmierung)... So - jetzt habe ich meinem ├ärger ausreichend Luft gemacht, in der Hoffnung, dass mit dem n├Ąchsten Update wieder einiges besser wird. Vielleicht bin ich da aber auch einfach nur zu oldschool... Muss jetzt mit Variante 3) weitermachen :-(
  16. Hi, maybe i'm too stupid - but this is driving me mad. I know (guess ?!) that in an older version of AD i was able to show or hide special characters like whitespace, paragraph etc. via a command from the dropdown menu (i guess Text or View ?!). Now i have made a new document in v1.7.1, inserted a text, but i can't deactivate the display of these special characters (Figure A) ). I searched the whole menus but i can't find the command to hide these. Am I blind ? E.g. in Affinity Publisher this command is located in "Text"->"Sonderzeichen einblenden" (sorry, don't know the english menu item). Figure B) Can someone help me please - thanks! Figure A) Figure B)
  17. sorry guys, but i don't think it's about Windows or font versions. I stil believe it's a bug in AD export itself. To not allways rely on Adobe Indesign or Illustrator, i made the same test with Scribus and exported a PDF/X-3:2002, which was instantly correct and passed the preflight test in Acrobat Pro. Nothing has changed on my Windows system. So why does this open source software do the job like expected and AD not ? scribus-test_1-1.sla scribus-test_1-1-pdfx3-export.pdf
  18. Hi Chris, i tried the latest public beta with my last AD test document. The Text with Roboto Light ist stil broken in the exported PDF. Additionally i created a completely new AD document and typed some German letters. As long as i use "Roboto Light" the error stil occurs. As soon as i change the font to "Arial" the resulting PDF ist ok. I tried switching the text language to none or German or English. Same error with Roboto Light. Attached you will find my latest AD test file and the two test PDF exports. And the currently installed Roboto fontset (downloaded from Google fonts some month ago) from my Windows 7 Professional system (SP1). ad-beta-109_1-1.afdesign ad-beta-109_1-1_roboto-light.pdf ad-beta-109_1-1_arial.pdf roboto-fonts.zip
  19. Jens, sorry you are absolutely right. I didn't mention that export setting. But meanwhile i'm so frustrated about all the "little" bugs in Designer. I really spent a lot of time with Affinity Designer during 4 customer projects in the last months. And there are a lot of little things to fix or optimize. Unreliable PDF export is just one of them. E.g. the whole text style section ("Textstile") is a m... compared to Illustrator (not much better) or InDesign. Or after working hours in a least more complex document (with several symbols and constraints), it's often better to restart the Application when even selecting an object needs 1-2 seconds to execute. I'm searching for a reliable professional replacement for Adobes crappy CC software since years now. Affinity Products look fine and do some great stuff. But before rollout the next "fancy" iPad app, it would be helpfull to make all the existing basic functionality really stable. I guess thousands of professional users (print and web) would appreciate that. Or maybe i'm just to oldschool
  20. Hi Jens, of course it's possible to convert text to path. But this is not the intention of PDF (font embedding is THE core feature of PDF). Converting all text to pathes needs timeconsuming massive extra work (copy orginal editable texts, hide it from rendering, show only converted path-texts, ...), because e.g. you have to do this after every change before creating a new PDF to send to your customer for approval. AND it produces a lot of extra data in your AD file. AND - the most important disadvantage - real text from embedded fonts is rendered and printed at highest quality with all features. Converted "text" is only graphics, which is at least renderd poor when viewed in Acrobat. There has to be a stable and predictable basic solution for any text i create in AD. --- By the way - the encoding problem occurs again. Nothing was solved after my first tests... So i made a quick test again with the same text. One example in AD and the same text in Illustrator CS6. This is a screenshot from AD edit view, where i created a simple box text in an artboard: After exporting it from AD with the PDF/X-3:2003 preset (no manual pref changes) and open it in Acrobat Pro DC the text is completely broken: If i do the same with Illustrator CS6 the exported PDF/X-3 result looks EXACTLY the same as the original Illustrator editor document: I stil guess it's an encoding bug in AD (Windows) export. I'm no PDF expert - but you can see some differences. Focus on the font embedding tab in the Acrobat document properties dialogue. AD uses "Identity-H" (whatever this means). Illustrator uses "Ansi", which seems not to be logical, because the text contains German mutated vowels and special characters?
  21. File size matters ! I use designer for web-design. As long as you work with pure vector and text, designer is a quite handy tool (despite some annoying bugs). But as soon, as you place images (typical workflow for webdesign) in your layout, it becomes really inconvenient. The filesize of the layout document EXPLODES and becomes really unpredictable. The size of a designer layout document becomes far bigger than the sum file sizes of the placed original compressed JPG or PNG images. I read somewhere in the forums, designer and photo store placed bitmaps uncompressed with the layout file - to speed up document loading? However, in my opinion this behaviour is not practicable. Some people may say: disk space is cheap, so why be so miserly? But first of all, all documents have to be backuped. And when it comes to data transfer it's a big difference if i can send e.g. a 20 MB file as email attachment or have to upload a huge 200 MB file to some document cloud. Filesize also means waste of time and other resources. We know the problem of Photoshop local smart objects. But PS stores/attaches the underlying bitmap data in it's original compressed format (JPG, TIFF, PNG etc.) and only points to it when rerendering an instace. I guess this is the correct method. If i have to transform the smart object instance later (e.g. design changes by customer), PS can allways rely on the original high resolution pixel data. But the PS document size increases only for the amount of the rendered instance layer + original bitmap attachment. It's even possible, to edit the smart object in place (isolation mode) and reduce the original bitmap resolution (destructive scale) without touching the instance position and size. In essence the filesize of the whole PS document is far smaller than a comparable AD document and approximately predictable. In essence: placed/imported images should either NOT be stored within the document. OR if stored within the document, then in it's original file format and compression. Placed images should not blow up the overall document size in the way they do now. Designer workaround - the rasterize dilema The only way i found to minimize document filesize is, to rasterize placed images, so they become a local pixel layer. This reduces overall filesize but the result is stil unpredictable. Sometimes the document becomes soon very small after rasterizing a high resolution image layer and saving the document again. Sometimes it becomes even bigger - later it becomes smaller again. So it seems, that redundant pixel data is not cleaned up at every save procedure? The bad thing: the document becomes smaller at the end, but now i loose everey connection between the bitmap layer and the orginal placed image. AND i loose every layer effects! I even don't know what was the original scaled size of my old bitmap. If i have to do design changes lateron (we all know our customers...) i have to spend extra time to search the orginal image, place it in its actual size, rebuild layer effects (hopefully made some notes in the layer label). After that extra work i can do the actual design changes. Much, much extra time spent! To prevent this, next time i leave the original image in the document and have - yes a huge file again :-( Another impractical point of rasterizing is the lack of control over pixel density. I'm talking about real count of pixels in the bitmap NOT the relative dpi (document settings). There is an ellipsis beneath the menu item "Layer -> Rasterize..." that meant to show an additional settings dialogue before rasterization is done. But there are no raster options to set. The document dpi has no effect on how the layer is rendered - to say how many pixels are created from the layer. And the rasterized quality is only moderate - seems to be 72dpi with method bilinear? There should be precise settings for the rasterize command: - absolute resolution: means, how many pixels are rendered per inch/cm (presets or explicit manual setting). - relative dpi (relevant for print) - render method: there should be an option for high quality rasterization of layers - e.g. bicubic andd so on. Simply compare this to the slice settings in the export persona.
  22. Hi Chris, thanks for your reply. I got the same error with the public Beta. 1) I installed the latest beta and exported the AD testdocument. The effect was stil the same - text with Roboto Light was broken in the resulting PDF document. 2) I deleted all Roboto fonts from my Windows, downloaded all fonts again directly from google fonts and installed them. Then i opened the AD testdocument with the Beta version and exported again to PDF. The same error occurs with Roboto Light. --- Then i had an idea! In the fonts panel i switched the language explicitley to German. Since then the error with the testdocument is gone! I went back to the release version and now the error is also gone. Now even new documents that use Roboto Light export correctly to PDF. And this works regardless which language i now choose in the fonts panel. Very strange, maybe some font caching effect... ? But - I also tried to export my orginal webdesign in which i detected the PDF error first. With this document now all Roboto Fonts are exported correctly but another font in the upper left logo is stil broken. In this case the font for the logo is "Univers 55" (Type 1). I also typed in the two words again. Same effect. Changing the font family to Arial or Roboto solves the problem. But it's a logo and has to use exactly "Univers 55". The original view in AD is this: But the exported PDF looks like this: The same error occurs in the latest Beta I guess there is a serious bug. Maybe from character encoding? On one hand it's strange enough that switching the language in the fonts panel once (first time after installation) will "solve" some font problems in general. On the other hand it seems to be unpredictable which fonts will stil produce errors at the end. Don't missunderstand - but Affinity Designer as the WYSIWYG "Editor" in which i created the text shows my design correctly. So i must be shure, that the exported PDF looks exactly the same. Otherwise the PDF export feature is rather useless. Imagine, i work on a design for hours and days and at the end i get errors trying to export a PDF that is meant to present the artwork to my client. Not really helpfull, isn't it ?
  23. This is my first post. I hope this is the right place to report the following bug. System: Windows 7 SP1, German Version: Affinity Designer --- I often use Roboto Light as a base font for web design. I did a screen design using several art and box texts with font Roboto Light. In AD everything looked fine. Also when exporting the screenshots to JPG or TIFF. But when i tried to export to PDF (all PDF presets) all the texts that use Roboto Light are completely broken showing messed up chars. I attached a simple AD testfile and the exported PDF/X-3 in which I reproduced the failure. bug_text-roboto-light-pdf-export_1-1.afdesign bug_text-roboto-light-pdf-export_1-1_x-3.pdf JPG export directly from AD: Screenshot PDF/X-3 opended in Adobe Acrobat Pro DC: If i check the PDF properties with Acrobat Pro DC i can see that all fonts seem to be embedded with subsets. Choosing another font (e.g. Arial, Roboto Regular, Droid Sans, ...) will export all these texts correctly. Is this an encoding / subsetting problem? I have this font installed in Windows: ROBOTO-LIGHT_1.TTF
  • 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.