anweid

In Affinity Publisher 2.0.0 for Windows, the pin studio behaves as illustrated in the attached video: At 0:00, the studio floats, and all studio items are nicely visible. At 0:03, you can see that the 'Layers' studio (and the 'Protocol' below it) can be nicely resized. At 0:09, I drag the 'Pin' studio into the same area that the 'Layers' studio occupies. The 'Pin' studio is therefore forced into the same dimensions, not all items are visible anymore, and a scroll bar appears. Fine. Unfortunately, the 'Pin' studio now can not be resized anymore, because no matter how I like to resize it, the mouse cursor never changes to 'north/south', and dragging the studio's borders is impossible. At 0:22, I change to the 'Layers' studio again. Here, resizing is still possible. At 0:30, I change back to the 'Pins' studio, where resizing is still not possible. The same thing might happen even if no studio is visible but the 'Pins' (not shown in the video): Even with a full screen height completely unused, the 'Pin' studio might become small vertically, and scroll bars appear. It would be nice if the 'Pin' studio could be properly resized as most other studios. Andreas Weidner pinstudio.mp4

Affinity Publisher 2.0.0 for Windows (and the previous versions 1.x, which I didn't bother to report) sometimes does not allow a pin to be positioned at a special location due to very weird behaviour. The attached video hopefully clarifies this: At 0:00, you see that the distance between text and a pinned image is set to at least 0mm. But the image frame does not repell the text quadratically as requested, but overlaps it a bit vertically. At 0:10–0:24, I push the image more to the bottom (using the scroll wheel above the edit field), and the text is always repelled the same not-quite-correct way, with a bit of vertical overlap. This is inconvenient, but not dramatic. At around 0:25, I change the value several times between 13mm and 12mm, and the result is drastic: The image is not moved by just 1mm vertically, but jumps to a completely unforeseen vertical position. At 0:35, I move the (wrongly positioned) image farther upwards. At 0:38, without any changes to any text flow, the vertical position of the whole text changes by some mysterious reason. Such strange behaviour occurs quite seldom, but when it does, I cannot make it go away. Hopefully you can reconstruct this problem with the attached file. Andreas Weidner pinproblem.mp4 PinProblem.afpub

All three Affinity 2.0.0 programs (not only Publisher) for Windows allow to change 'text contrast' and 'app lightness' (or whatever those are called in English) in their settings (see attachment), which is nice: I like to set both of them to their leftmost value. Unfortunately, both of these settings are not saved to disk. Every time any of the programs is closed and restarted, these settings are reset to their default values. It would be nicer if the Affinities would remember these settings between sessions. Andreas Weidner

Thanks for the tip with the TrueType-specific metrics: For all italic fonts, all metrics, especially WinAscent and WinDescent were wrong. The type foundry was even so friendly as to provide me with updated fonts with correct metrics – wonderful! Unfortunately, for these updated fonts, the weight information is wrong everywhere, so again all programs become confused. I will keep contact with the type foundry, and either they correct the values, or I just correct them myself with my ten year old battered copy of 'FontLab Studio 5.2'. This is also where the screenshot comes from – newer versions of that software are not to my taste... Andreas Weidner

With 'pixel-based printer' I mean any printer driver that requires the operating system to convert everything to pixels before sending it to the printer. This is in contrast to Postscript-based printer drivers, which convert everything to Postscript vectors, and the conversion to pixels is done by the Postscript interpreter inside the printer itself. The problem happens with all printers that are not Postscript (but I only have two such printers, one being an Epson inkjet, the other the SnagIt 2022 virtual printer). Since the font version you have seems to be TrueType format (2048 UPM), it differs from mine, which is OpenType (Postscript outlines) with 1000 UPM. It might well be that your version is wonderful, but mine isn't by some reason. Further investigation produced the following results. Since printing on paper with my Epson printer produced exactly the same results as the SnagIt virtual printer, I only tested with SnagIt this time: The problem also appears in all other applications I tried: PagePlus X9, InDesign CS5.5, LibreOffice 7.2.6, WordPad, TextMaker 2021. In the latter, the problem can also be seen directly on screen during typing. This makes it highly probable that the problem is really the font itself – otherwise, TextMaker and two printer drivers would need to have the same bug. Therefore, I withdraw my bug report and declare that it's not a problem of Affinity, but the font is somehow screwed up. Perhaps manually correcting the metrics will help. I will try that in the next months... Andreas Weidner

Affinity Publisher 1.10.5.1342 for Windows behaves as follows: When using the font 'Landa Italic', all descenders are clipped away when printing to a pixel-based printer. Screen display, printing to Postscript printers, export to PDF and export to pixel images all work fine. Since I couldn't reproduce this problem with any other font, it's probably some strange issue with the font metrics. Though the ascenders grossly differ, all other metrics seem to be rather similar. I don't know why the font foundry defined the metrics this way, but, since everything but the pixel-based printing in Affinity Publishers works nicely, I still think this might be a Publisher bug. In the attachments, the pixel-based printing is simulated with the '...-SnagItPrinter.png', which produces the same results as a 'real' print on a non-Postscript printer. This of course is low-priority, since printing the PDF export is an obvious workaround. In case you do want to check this further, I can send you the font files to a private link (they're commercial and licensed). Andreas Weidner TextCrop.afpub TextCrop.pdf

Aaaaah - so it was the third option! I never expected this list to be collapsed directly after loading a file, so I never bothered to check - too bad. Thanks. Andreas Weidner

The German Affinity Publisher 1.10.1.1142 for Windows behaves as follows: With a text editor, create a CSV file with the following content (Windows line endings #13#10): a,b,c,d 1,2,3,4 2,4,6,8 In Publisher, create a new document without content. Show the Data Merge window and load the CSV file. 4 fields, 2 lines are found. Fine. The automatic detection of commas or semicolons does not work, but after manual adjustment, these values are correct. But the Fields panel doesn't show anything (see screenshot). No matter what I tried, which CSV files I loaded, whether I used commas or semicolons, whether I followed your tutorial https://affinity.serif.com/de/tutorials/publisher/desktop/video/494072789/ or not, the Data Merge window always shows the correct number of entries, but the Fields panel never, ever shows anything. Either that's a bug, then it would be nice to have it corrected, or I'm just too stupid for the data merge function, then it would be nice to have it more intuitive to use (currently, I'm completely confused by that function). Thanks. Andreas Weidner PS: A third option of course would be to somehow make me less stupid...

The German Affinity Publisher 1.10.0.1098 for Windows reliably destroys existing layouts (saved with previous versions) under the following circumstances: In a multi-page document, insert some graphics (or table or whatever) and pin it as a character to flow with the text. In order for the image to be displayed properly, do not use a fixed line height, but keep the automatically determined one. In previous versions of Publisher, this works reliable ('BreakOK.png'). In the new beta, if any such image-containing paragraph begins at the top of a page, the image is moved to a wrong position, and the layout of the rest of the document is destroyed accordingly ('BreakBug.png'). Please find attached also the original document saved with version 1.9.2.1035 (which version 1.9.4.x could also properly read). It would be nice if the original correct behaviour could be restored. Andreas Weidner BreakBug.afpub

Thanks @Joachim_L and @HeikoM81: Zipping common web formats to prevent the forum changing these files is a good idea, but was not necessary in this case: I got reliable crashes on all images downloaded from this forum thread – even the ones containing only device specifications or the very small crashpad handler screenshots. The crashes appeared when hardware acceleration was switched on (see attached screenshot). After switching the acceleration off, I could not recreate the crashes anymore. Wonderful! After switching the acceleration on again, I could also not recreate the crashes anymore. Though that's nice, it's got me confused now. Let's hope that the crashes don't reappear in the future... Andreas Weidner

...and yet another reliably crashing image, this time with my i7 (16GB). Andreas Weidner

I forgot to add: No crash reports are available. Buuuuuut: At least I now found a picture that reliably crashes even after saving to disk and opening it again: By coincidence, I created a screenshot while a second monitor (4k) was attached, which resulted in the attached (stupid) image. Saving, reloading, not cropping, not rasterising, but directly dragging the magic wand across one of the white areas very quickly produces a crash (only tested on the i5 machine). Andreas Weidner

This is what Windows tells me about my two computers (one at home, one at work). The i5 with 8GB crashes often (50%?), the i7 with 16GB less often (10%?). The i5 mentions pen support: This is because I installed a graphics tablet a year ago, which is not connected to that machine since several months, so I only use the mouse exclusively. Andreas Weidner

The German Affinity Photo 1.9.4.1065 (and the last non-beta version 1.9.2.1035) for Windows very often crashes (50% of all cases) if I do the following (see attached video): Visit a web page containing an image and put a screenshot on the clipboard (0:00-0:04). Switch to Affinity Photo and create a new image from the clipboard (0:04-0:11). Crop the image and rasterise it (0:11-0:30). So far, so good. Now, in order to make the background transparent, use the magic wand, press the mouse button over a white area and move the mouse in order to adjust the tolerance. This works for a few tolerance settings, but at some point (0:44), the application stops responding and has to be killed manually. For some pictures, this happens during the first second of mouse moving. For others (like shown), it takes a lot of fiddling to get a crash. For only around 50% of all images, everything works properly. This problem does not happen when I manually set the tolerance to a certain value and then just click (not drag) inside an area. Only the dragging produces crashes. This problem does not happen if I load an image from disk. Only images copied from the clipboard produce regular crashes. As far as I remember, this problem first appeared in version 1.9.2. In 1.9.0, everything was correct (I think). Andreas Weidner magicwandcrash.mp4

Unfortunately, 'Flatten Transform' does not do the trick: Yes, it throws away the three or four rectangle transformations and therefore makes the resulting SVGs a little bit smaller. No, it still keeps the >150 completely empty but named groups. I therefore still consider this a bug... Thanks for the tip, though – this made me dig a bit deeper and realise that I can define my own export presets that afterwards appear in the slice options. I didn't know that before. Andreas Weidner

SVG slices exported with the German Affinity Designer 1.9.2.1035 for Windows might contain a lot of unnecessary (=empty) groups: In the attached screenshot, every smallish rectangular area contains an icon. In order to structure this amount of icons, each of them is put into a separate named layer. For each rectangular area, a slice with the same name is available, so that a large number of SVGs is created on export. The created SVGs look nice, but have a comparatively large file size. Attached is one of them. Looking through the SVG source, it appears that every named layer is included into the final SVG as a group, even if this group is completely empty. Excerpt (lots of empty groups before and after that): <g id="Meander"> </g> <g id="Mark"> <rect x="872" y="242" width="2" height="20" style="fill:rgb(160,160,160);"/> <rect x="870" y="258" width="20" height="2" style="fill:rgb(160,160,160);"/> <g transform="matrix(1,0,0,1.33333,1,-84)"> <rect x="881" y="249" width="2" height="6"/> </g> <g transform="matrix(1.33333,0,0,1,-293,-8.52651e-14)"> <rect x="879" y="251" width="6" height="2"/> </g> </g> <g id="Lock"> </g> <g id="LbrPackage"> </g> <g id="LbrOpen"> </g> <g id="LbrDevice"> </g> <g id="Lbr"> </g> Here, even the rectangle transformations would not be necessary, but let's just forget about those... It would be nice if at least the empty groups would be excluded from the export. In the attached SVG, this would reduce the number of lines from 428 to 16, and the file size from 9375B to 997B. Andreas Weidner Mark.svg

Apparently, 1.414 is not Designer's miter limit default – all rectangles I created in new documents always used 1.5, which is exactly what I suggested, anyway. Wonderful. I don't have the slightest idea where the miter limit of 1.414 came from in that document... This still leaves the matter of making the rounding zoom-independent. Andreas Weidner

The display of corners in the German Affinity Designer 1.9.2.1035 for Windows depends on the current zoom level. In the attached video, the red outlined rectangle uses sharp corners with a miter limit of 1.414, which seems to be some default (I would never enter this number myself). The following happens: Depending on the zoom level, the corners are all OK (0:00), or cannot really decide whether to be mitered or sharp (0:04), or are all mitered (0:13). This could be the result of problematic floating point rounding for the miter limit: 1.414 is very near sqrt(2), and sqrt(2) happens at exactly 90 degree corners. It appears that, depending on the zoom level, each corner's miter value is sometimes rounded to more than 1.414, resulting in mitered corners, and sometimes rounded to less than 1.414, resulting in sharp corners. Should this be the case, I suggest the following things: Set the default miter limit to a value that can be exactly (without round-off error) represented as binary floating point and is a bit larger than sqrt(2), e.g. 1.5. This would ensure that (1) sharp corners with 90 degree still behave as expected and (2) rounding does not depend on the least significant floating point bits. Do the rounding independent of the current zoom level – the corner display should be the same no matter how far you zoom in or out. Andreas Weidner StrangeCorners.mp4

Windows tells me the following things: Prozessor Intel(R) Core(TM) i5-8500 CPU @ 3.00GHz 3.00 GHz Installierter RAM 8,00 GB (7,78 GB verwendbar) Systemtyp 64-Bit-Betriebssystem, x64-basierter Prozessor Stift- und Toucheingabe Unterstützung für Stifteingabe Edition Windows 10 Pro Version 20H2 Installiert am ‎29.‎06.‎2020 Betriebssystembuild 19042.928 Leistung Windows Feature Experience Pack 120.2212.551.0 Andreas Weidner

Done: 'EAGLEIcons-20px.afdesign' Andreas Weidner

OK, thanks – I didn't know about the possibility of adjusting the passthrough level check. Buuuut now the following things happen: If I set the preflight to check for PDF-1.7, the 'PDF-1.4' incompatibility warning vanishes, and the table is not rasterised on export to PDF-1.7. Fine – that sounds logical. If a set the preflight to check for PDF/X-4, the incompatibility warning appears again, and if I then export to PDF/X-4, the table is still not rasterised (which is wonderful, but then the preflight warning seems to be useless). If I set the preflight to check for any other PDF/X type, the incompatibility warning appears, and when exporting to that format, the table is still not rasterised, but a lot of other things are (everything that lies behind the surrounding rectangle of any Publisher object using a white glow). Try as I might, the table is never rasterised (wonderful!). Therefore, I still think that both preflight warnings should not appear. Since the original second warning can only be seen properly if the original file is available, it is attached now. Andreas Weidner 1MHzCheck4-partlist2.pdf

The German Affinity Publisher 1.9.2.1035 for Windows behaves as follows: The attached document contains two placed PDFs containing vectors only: The table at the left was cropped, the image at the right retains its original form. The red objects were manually inserted with Publisher itself. The preflight check complains twice that the table will be rasterised on export due to two reasons. The wonderful thing is: The table is not rasterised on export, which of course should stay that way. The only things that are (correctly) rasterised are the white glows around the red objects. Since the table is not rasterised on export (which is desirable), it would be nice if no corresponding warning would be shown during preflight. Andreas Weidner PreflightMessage.pdf PreflightMessage.afpub

The German Affinity Designer 1.9.2.1035 (and all known versions before that) for Windows reliably crashes under the following conditions (see attached video): On a file with a large number of slices, scroll bars appear for the slices list. Fine. I do not scroll through this list by dragging the scroll indicator, but use the mouse scroll wheel instead (no problems happen when dragging). Scrolling to the end of the list (at 0:12) is possible, Designer uses around 6% CPU time. Fine. Expanding the last slice in the list (0:13) makes the list take up more space, so the scroll bar reflects that. Now I mouse-wheel-scroll slowly to the end of the list, which by some reason now contains lots of unused space at its end. At 0:16, though I still scroll down, the list jumps up, Designer freezes, CPU usage increases to 25% (which is 100% of one core), and Designer can only be killed manually. Since I only have this one file with as many slices, I don't know whether or not the problem is repeatable with other files. If you need the file for debugging, please send me a private link – I may not post this publicly... Andreas Weidner SliceCrash.mp4

The German Affinity Publisher 1.9.2.1035 (and all known versions before that) for Windows reliably crashes under the following circumstances: The attached document contains a text with the index mark 'marker' plus an index. Double-click on the word 'marker' on the second line to select it. Open the dialog for index mark insertion. The word 'marker' automatically appears in the combo box, and the combo box drop-down containing this word is also visible. Everything looks OK. Now do not click anywhere with the mouse, but just hit the Return key. Publisher crashes and is killed immediately. This seems to always happen if the word entered into the combo box matches an already existing entry, the combo box drop-down is visible, and Return is pressed. When clicking the mouse to close the combo box drop-down, everything works properly. Andreas Weidner IndexCrash.afpub

This problem seems to be corrected in version 1.9.0.920. Thanks. Andreas Weidner