Jump to content

anweid

Members
  • Posts

    136
  • Joined

  • Last visited

Recent Profile Visitors

911 profile views
  1. 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
  2. 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
  3. 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
  4. 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
  5. 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...
  6. 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
  7. 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
  8. ...and yet another reliably crashing image, this time with my i7 (16GB). Andreas Weidner
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. 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.