Jump to content


  • Content count

  • Joined

  • Last visited

  1. 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)
  2. Having the new linked resources feature with the resource manager is a very good step in the right direction. But this stil does not solve the problem i mentioned in earlier posts regarding the huge document filesizes that Affinity Designer and Publisher produce. It seems that as in AD the linked images in AP are stil stored within the document. And they stil seem to be stored uncompressed. Furthermore the filesize is unpredictable. Sometimes after deleting a picture frame with a linked image completely from the document, the filesize drops sigificant. Sometimes it gets even higher!? Overall the filesize increases significant with every single image that is added. I expected this issue to be solved with the linked resource, but a closer look tells us: it is not. I placed these two well known sample JPGs in a new blank AP document. As you can see in the Resource Manager both are linked and they are about 380 KB and 780 KB in original filesize. After saving the AP document the overall document filesize results in round about 3.7 Megabyte! And this is caused by only two midres images (1024 x 768 px). Imagine a poduct brochure with hundreds of images in print resolution. The document filesize will be some hundred Megabyte or more. But things get even worse after using the exact same linked image with two picture frames. I would expect, that at least both frames internally reference the same image data. But instead after saving the document the document filesize has increased to now 5 Megabyte! I don't know the reason for this stategy - not in Affinity Designer and especially not in Publisher. The latter is a tool by nature that has to deal with lots of external resources in one document. It's main purpose is to bring text and image together in a layout. Not to collect - and not to produce even more - redundant data. I am absolutely convinced that, like me, the majority of professional users keep a close eye on their computer resources. And it does matter when a single layout document is bigger than the sum of all its contained images. At the latest when it comes to archiving and backup. The strategy might be as easy as this (compare it to InDesign or Quark): 1) linked resources might only stored as rough lowres previews within the document. When opening the document the lowres version is displayed which will speedup loading. Then you can decide whether or not to show the layout in full highres resolution in the viewport. The option to switch between rough layout preview and highres design preview will always meet the needs of texters AND designers because both have different priorities when working with layout tool like Publisher. 2) embeded images will be stored within the document. But please, please as references to the embeded original data stream (jpg, tiff, etc.) - not as uncompressed bitmap which drastically increases the document filesize. I know this needs a huge amount of infrastructure behind the sceenes. But with the introduction of the linked resources you have the chance o build this the right way right from the start. The next step is as background process, that watches for changes in the linked resources and displays notifications about external changes (e.g. like the yellow warn icons in InDesign, that inform about external updates). Now sorry for saying it that clear. I really appreciate your efforts to provide clever tools (Photo, Designer and Publisher) with a professional, nice and clean UX and some cool features where even the f...... Adobe guys should take an example of. And i don't expect a "smaller" application with a "lower price" to have the full featureset like an "expensive one" with a "high price" (InDesign, QuarkXPress). The question is - should Affiity Publisher be a professional tool that is somehow comparable to these "top dogs". Or is it just a "nice small" tool for "low budgets"? E.g. CorelDraw is out now for almost 30 years. That was my first layout software I had to struggle with in the early 90's. If you look at it now, it's UX is nicer. But under the hood lot's of stuff is done the same way as 25 years ago - no really huge evolution. You can use it professionally if you have to. But it's not comparable at all to an actual version of Affinity Designer or Photo which offers modern techniques and workflow approaches. But the Corel Suite is still sold for actual 594,00 €. Not exactly cheap for a set of software which is not matured in the best manner. As far as I'm concerned, I was and I am always willing to pay a good, reasonable price for a good software tool. If it makes my daily work as a designer (craftsman) really easier and faster it will always be a good invest. Cheers.
  3. Hi Chris, i tested Beta I guess, the scale/position/clip of the picture frame content with properties autofit set to 'none' now works as expected. As RyS mentioned, maybe a nice addition would be some contextmenu commands regarding fit content to frame or fit frame to content etc. But the basic behaviour now is OK to my mind. OK, there is one thing I forgot: at the moment it's possible to group the picture frame (with itself) to scale the box together with it's contained image element. This solves the problem of having a well prepared picture frame with the right image aspect and so on, that afterwards should be scaled up or down as a union. To edit the picture frame box one can doubleclick the group to be able to change the frame with the side/corner controls. By holding STRG-key while clicking on the contained image element you can directly select this and work on the image element independently. So far so good :-) Nice addition would be: instead of always having to group the picture frame there might also be a keybord modifier combination, that makes the picture frame behave like a group during scaling. Maybe STRG+SHIFT+ALT when scaling the frame scales it as a group. Without modifiers the frame scales independent from it's contained image element. just an idea for working even more fluid... Thanks
  4. Hi, first of all, thanks for your intense work on Publisher to complete the Affinity "family" ;-) Following remarks to the public Beta 1.7 1) To my mind, the default behaviour in AP should be to link images rather than to embed them. I guess this meets the nature of the application better because as a page layout tool (like InDesign or QuarkXPress) you rather deal with a lot of images in one document. Furthermore the typical team workflow may be that one person does the layout while another one does image editing. 2) There is a strange behavour with the image fit when scaling and streching the pciture frame. Autofit (max, min strech, none) meight be handy in some scenarios when the images are prepared in the exact size and crop. But mostly you don't not know the exakt crop and resolution until you placed the image in the page layout - tweeking it a little bit to see how it looks in the context of the whole layout. In AP there is the positbility to resize, rotate and pan the image contained in the picture frame to get the desired crop (double clicking on the frame activates the masked image). But as soon as you resize or strech the whole picture frame again, the image snaps back to the auto fit behavoir and all your manual sizing, positioning and croping is immediately gone. Even when setting the picture frame property to 'none' (no auto scaling), when resizing the whole picture frame the image is scaled to its original size (as it says - allways switch to original size...). All manual croping an paning is gone. This missbehaviour is even applied if "lock children" is active on the picture frame. This auto fit behavoiur is absolutely counterproductive in most cases. E.g. InDesign shows how an image frame should behave: - Any manual resizing and positioning on the inner image is maintained. The position is relative to the page scope - unless you move the picture frame as a whole. Then the image is moving with the frame. When resizing / stretching the picture frame by the side or corner controls, the inner image is typically not scaled and stays at its global coordinates. Only if you press some modifier keys while scaling the picture frame, the content is scaled with its parent as a group (either proportionally or squeezed). Why is this usefull? For example if your layout was OK but afterwards you may have to extend the document bleed and have to resize picture frames that extend into the bleed. Or imagine after some text changes the text floating around a picture frame does not longer look that good. You may have to tweek the size of the picture frame a little bit to get a better hyphenation. In all cases your previous image aspect will be dropped. Not funny... To wrap it up: - any imported resources - regardless of whether this is bitmap or vector - should be linked by default instead of embedded. Embedding should be the option. - content (picture) frames should not influence their content by default (unless moved or scaled as a whole) when resized with the box controls ("anchors"). Auto fit should be an option but not the default. Or make this customizable via the app prefs. By the way: please implement this linked resource behaviour (and the resource manager) directly in Affinity Designer because there every imported and embedded image inflates the document filesize dramatically. And even in Photo linked resources might be a really cool feature (compare this to Photoshop linked smart objects)...
  5. 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
  6. 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
  7. 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
  8. 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?
  9. 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.
  10. 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 ?
  11. 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