techfips

Wow, thanks for spotting that! Indeed, removing it did the trick.

When trying to export attached drawing as a PDF, Affinity Designer 1.8.4 states an unknown error occurred (and could also not pre-calculate the file size). I am wondering what is broken with this file that prevents PDF export, while SVG works just fine..? The same error occurs in 1.9.0 beta. polarbar.afdesign

A bottle of champagne to the devs! Thanks for making this working smoothly (again). Much appreciated.

Thanks for making me aware of the existing thread! I see that I am certainly not the only scientific user of AD that got their workflow messed up. As such, I can only hope for an option to get back the importing as artistic text... I would add to the general dissatisfaction with regard to many folks, group leaders, etc. advertising AD to their peers and students as a really useful product for brushing up scientific illustrations/diagrams, but lately that promise cannot be kept as much as I would like it to.

When using the "artistic text" tool (first attachment), then exporting to PDF and reimporting/opening (irrespective of the combination of the checkbox settings), one ends up with a "frame text" that is sitting in a box larger than the original text demands (see second attachment)...

This problem has been fixed in the 1.8.2.1 beta. My thanks to the development team!

I would like to add support to having text imported from PDF as artistic text instead of (the current state) as oversized frames; this is indeed a major nuisance for our workflows as well.

A path along the nodes (A:0,0) -- (B:1,1) -- (C:2,0) -- (B:1,1) -- (D:2,2) cuts out the segment (B) -- (C) upon exporting to PDF. This bug is extremely annoying and still present in 1.8.2.0 beta..! testcase.afdesign testcase.pdf

True, but unfortunately the same issue is still present in the newest 1.7.125 beta of Affinity Photo—developing without any active filter/adjustment results in perceivably correct shading compared to batch importing with saving as either JPG or PNG that produces notably darker shades (apparently, roughly the upper third of the histogram is never used). I am quite puzzled how such a serious drawback can survive in the program for such a long time..? APh seems to be the goto solution for RAW processing, but a critically flawed batch import is rendering the whole program much less (if at all) useful for professional work.

Was trying the crop tool and am surprised that the live indicator of the final image dimension jumps between correct values and (probably) integer fractions of it when moving the frame? I attach a snapshot of a cropping action where the dimensions are far off... Oops, should probably have been posted into bugs--where the same issue is already raised as I just saw. However, I would add to that existing bug report that it is not only a factor of two by which the reported dimensions are off, but can be even smaller and change with each pixel of frame motion.

Variable end capping (with arrows, circles, squares, you name it) is indeed very useful. I would like to add a request for the feature to have the position of the "capping" object also as a variable. In other words, start and end (0% and 100%) being only special cases of a more general capability to place objects (or text!) along a path.