Jump to content

4dimage

Members
  • Content count

    17
  • Joined

  • Last visited

About 4dimage

  • Rank
    Newbie

Recent Profile Visitors

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

  1. That's interesting. Then the effects (unsharp mask) are not cliped by the picture frame boundaries. Hope you can fix this :-)
  2. 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 ?!
  3. Hi Sean, document is uploaded to dropbox. Good luck By the way - the collect option in 1.8 will be a great helper :-)
  4. 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 ?!
  5. AD version 1.7.3.481 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... :-(
  6. 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 :-(
  7. 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)
  8. 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
  9. Hi Chris, i tried the latest public beta 1.6.5.109 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
  10. 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
  11. 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?
  12. 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.
  13. Hi Chris, thanks for your reply. I got the same error with the public Beta. 1) I installed the latest beta 1.6.3.99 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 1.6.2.97 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 1.6.3.99. 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 ?
  14. 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 1.6.2.97 --- 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
×

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.