Jump to content
You must now use your email address to sign in [click for more info] ×

mqudsi

Members
  • Posts

    166
  • Joined

  • Last visited

Everything posted by mqudsi

  1. Thanks for the confirmation, @Dan C. I look forward to hearing good news!
  2. Thanks - seems doable, if unnecessarily long for a one-liner. Can you specifically ask if we can at least change the behavior if a specifically non-breaking space (U+00A0) is used? I'm sure that would preserve whatever reasons they have for trimming trailing whitespace, while allowing this quicker workaround.
  3. I've already attached it to the first post I'm assuming it does do just that.
  4. I'm fine with most keyboard shortcuts the way they are, but for the life of me I can't get used to the discrepancy when it comes to zooming: the Affinity suite zooms with ctrl+scroll and uses alt+scroll to rotate an object about its axis, while Illustrator zooms with alt+scroll and just scrolls left/right with ctrl+scroll. (Also, is rotating the selected object used so commonly that it merits the very coveted ctrl+scroll shortcut? I wish Serif just used both alt+scroll and crtl+scroll to zoom instead). Anyway, I can't seem to find a way to change this in the keyboard shortcuts section. Is it possible?
  5. With a textbox set to right-aligned, I can enter trailing whitespace in Illustrator to manually offset the text in a multiline textbox by some pixels: In Affinity Designer, any trailing whitespace is ignored when the text is rendered, regardless of whether I use regular spaces (U+0020) or even non-breaking spaces (U+00A0): (Notice how the text insertion caret is blinking outside the bounds of the multiline text box because the whitespace is completely ignored for font setting purposes.
  6. Both the source text and the correct rendered result are preserved w/ full editing capabilities in Illustrator. The textbox contains lowercase, the smallcaps option is on, the text is rendered with uppercase glyphs. Changing the text (upper to lower or lower to upper) has the correct and expected result. Copying-and-pasting from Illustrator to a text editor presents the correct MixED cASe as expected. Yes, though to be honest, I said as much when describing how the metadata was used to store the editability information. AD imports plenty of "non-standard" things from Illustrator-created PDFs to get them to render OK. We're in agreement on this, so long as you are saying the underlying code points for what is rendered in the PDF are uppercase. That's pretty much what I said above about PostScript, the AD bug regarding with which glyphs are subset, and what the editor source contains vs what the generated PDF has.
  7. The first, (square aka not affinity). The pixel mask is the bug I am describing - I'm not finding any other PDF viewer/editor that doesn't render that file as fully vectorized; only AD rasterizes the mask (which exists to provide a color overlay for editability purposes). I'm guessing there's something about it that AD doesn't understand or yet support.
  8. Thanks for the reply and no worries about the earlier confusion. I just needed to make it clear that this wasn't a case of user error so we could get to the juicy stuff I played around with import/export in Affinity Designer and I see what you mean about the subsetting. I think that the behavior in question is an AD bug though - an incorrect subset of the characters used in the document is subset in the PDF, because the mapping between lower- and upper-case underlying text vs rendered text is not taken into account. The lowercase glyphs from the font are subset instead of the uppercase glyphs that are actually rendered, so when I open the AD document in another editor (Illustrator), only the initial (capitalized) letter of the small caps text is rendered correctly, while the rest are rendered with the missing glyph symbol. This is not the behavior when going the other way around and exporting the document from Illustrator with font subsetting enabled. I'm aware that the raw PostScript layer doesn't understand the concept of "small caps" but to go a step further, it doesn't understand any font-to-glyph (or glyph-to-font) mappings in the first place. Neither Illustrator nor AD are really working at the core PDF layer (intended for rendering, not editing), but rather using the additional metadata specifically emitted in the PDF to allow for editability. For what it's worth, there is nothing preventing AD from doing whatever it is that Illustrator does when given the same blackbox PDF input. Illustrator is able to understand (via the metadata) that the text is in lowercase rendered in uppercase glyphs, and for AD to be truly compatible as a drop-in Illustrator replacement, imho it should too. [quote]Does Illustrator also have an option to subset the fonts? Did you choose it? If so, could you tell Illustrator to include the full font, and if you do that does it resolve the problem?[/quote] Illustrator has a font subsetting option enabled by default, but it does not matter if it is on or not with regards to how AD interprets the input (because Illustrator is correctly subsetting the glyphs in use). BTW, this isn't just a matter of AD not being compatible with how Illustrator stores its text characteristics metadata (or else a lot more text metadata would be lost probably making it impossible to actually open any Illustrator-generated PDF in Affinity Designer for editing). From what I can see, the subtleties of how smallcaps text is exported, imported, and treated throughout the pipeline hasn't really been taken into account at all, even with Illustrator completely out of the picture. Aside from the matter of incorrect subsetting, AD can't understand its own smallcaps output if the exported PDF is imported right back into AD (the text is imported as lowercase). That's just how smallcaps was interpreted for the PDF preview. The source file it was generated from had MiXeD caSE text w/ smallcaps on, the resulting text does copy as all-caps in a viewer but if the PDF file is opened in Illustrator instead, the correct MiXeD caSE text is preserved (w/ smallcaps effect).
  9. An "AD-native" drop shadow added via as an AD fx to a layer, when offset sufficiently so as to appear above or behind any (non-curves) vector text, causes the resulting PDF export to export "anemic" strokes for the text (and I don't know how to word it except like this). This was actually pretty hard to track down since the drop shadow is exported correctly but seemingly random text in the document with identical properties (font family, font face, kerning, etc) would end up looking wrong in the resulting PDF export, while other similar text in the document would be fine. Here's what the text looks like in AD (note the drop shadow behind the circle and how it extends to make contact with the adjacent text): vs here's what the resulting text from the exported PDF looks like when viewed in any PDF viewer: As you can see, the kerning and the weight of the strokes is very much off. If you export to a raster format like tiff, the text is exported correctly. There are two sets of identically formatted text in this document, one overlaps the dropshadow and the other doesn't. Here's the difference between the generated PDF and the generated TIFF where the drop shadow is found (red denotes found in the tiff but not in the pdf, you can see how it's the stroke width that's affected, giving the "amemic" result): And here's the tiff vs pdf comparison of the other text from the opposite side of the document where the drop shadow falls to the other side, meaning it doesn't overlap the text: As you can see, the heading text is a fairly close match with only a slight deviation in the stroke width between the two. Something else in the document is overlapping with the subheading causing more anemic text to be generated here - my guess is that it's the same underlying issue, just not caused by the drop shadow (hence the more generic "overlapping translucency" in the title). For what it's worth, Adobe Illustrator 2022 can export the text correctly (not just when converted to curves) with the overlaps. The affected document is attached. Fundraising Dinner 2021 - 9x4 with Keynote.afdesign
  10. Walt, Please read my post carefully: this is not an issue with an unsupported font or else I wouldn't have been able to make the corrections in AD that I did to get fix it. I've identified the actual problem and it has to do with the associated text properties being lost on import. (Aside from that, this is all on the same PC.)
  11. The attached PDF is rasterized when opened in Affinity Designer but displays fine in all other viewers/editors that I've tried. I imagine there is an unsupported vector property that AD is choking on. I was able to manually correct this and generate an equivalent PDF fully in AD from the same source file, so I'm not sure why the automated import fails. CPSA Book (Square).pdf CPSA Book affinity.pdf
  12. I have a PDF created in Adobe Illustrator that displays fine via multiple different SDKs and toolkits across different platforms. The PDF contains text (set in Iowan Old Style) that was configured via the "Character" panel in Illustrator 2022 to use small caps, as shown below: The resulting PDF is not correctly imported; here is an example: What it should look like: What is displayed in Affinity Designer 1.10.4 when the PDF is opened (without selecting "favor editable text over fidelity"): As you can see, the kerning is all wrong (all characters are rendered much closer together), the characters are all caps (the actually capitalized input is not rendered at a larger size than the remainder of the text), and the numbers no longer match the height of the neighboring letters. Manually selecting the text input and turning on "Small Caps" in Affinity Designer corrects the height of the numeric characters at the end, but the text kerning remains incorrect - it seems that the underlying text is imported as all-uppercase even though it isn't: This is verified by manually selecting the last three letters of "LIVE" and re-typing them (in lowercase). This, with the previous step of enabling small caps for the text box gives the corrected result: I've attached the actual PDF exhibiting this incorrect behavior as exported by Adobe Illustrator (i.e. without any corrections from Affinity Designer). Fundraising Dinner 2021 - Web.pdf
  13. I suppose that means timer events should be classified into "fires in background" and "doesn't fire in background" with the default being the latter? Presumably that would address/workaround (without fixing)
  14. AD/AP should block all processing/rendering/etc threads when it is not the active window or when it is minimized. Active tasks (the type that would present a progress dialog like export/save/etc) should of course not be suspended, but there's no reason for AD to be rendering the canvas when it's in the background. Additionally, all tabs except the current tab should always be suspended. The CPU (not memory) profile of AD when open with a single tab active (and not "multiple documents mode" enabled) should be identical whether that tab is the only tab loaded in AD or one of a hundred.
  15. Thank you both for explaining. I understand the difference between cropping and clipping, but it was @MEB's point about visibility's role in all this that cleared things up. I now understand (but still disagree with) the results that AD presents. It is a difference in how AD treats objects vs how other software might. As a vector-based program, I would expect AD to treat a filled object and an unfilled object exactly the same, except in how they appear (i.e. unfilled is "filled but with transparent background"), whereas for a pixel-based program like AP or Photoshop (where masking comes from in the first place) it makes sense for masking to work on colored vs uncolored. But when it comes to vector objects, an area "is present" when it has an enclosed path, not when it has color. For a rasterized/flattened pixel layer, AD should treat masking the way it does: by colored vs uncolored. But for vector objects, the definition of "existent" is fundamentally different, and imho only whether or not a closed shape exists and not whether it is filled with a color or has no fill should play a role.
  16. Thanks for the reply, Sean. The terminology is eluding me, but (referencing your images from here on out) I'm not understanding how the 4th image (bottom right) is correct. Each row has the same operation performed on it, each column has the same items/color. The operation performed in the second row, as demonstrated in the first column, results in the intersection of the two shapes being retained. The green fill of the rectangle does not appear anywhere in that resulting image. When the only change that is made is that the green fill is changed to no fill, we go from "intersection of the two shapes retaining the fill of the red rectangle" to "stroke of second shape in the color of the first, and the intersection of the two shapes with the (no) fill of the second shape (rectangle)." I am extremely confused how, if the only difference between operations 3 and 4 is the fill of the second shape which does not appear in the final result per image 3, do we end up with a completely different result.
  17. It seems that masking is broken in the case of an unfilled mask (i.e. fill color: none) under 1.6.2 no fill masking bug.afdesign
  18. This is a feature request to add an option to the right-click transform menu when right-clicking on an artistic text element or a textbox element to convert between one and the other. Currently, one must cut the text, delete the element, create a new element of the other type, then paste the text.
  19. @Chris B So I just tried this... is it just me or does AD not allow multiple shortcuts mapping to the same action? I don't want to lose ctrl+w, but I want to map ctrl+f4 to do the same.
  20. This is a feature request to add an "edit layer in AP" context menu item to Affinity Designer when right-clicking a raster layer in the layer browser control.
  21. Thanks for the reply, Chris. I understand, I've actually already done so myself. This is a suggestion/feature request to support this keyboard shortcut out-of-the-box on Windows.
  22. On Windows, ctrl+F4 plays the same role as ctrl+w on all other platforms; namely, it closes a single document/tab in an mdi without closing the app (at least if other documents are open, as contrasted with alt+f4). Since ctrl+f4 isn't mapped to anything else atm, it should be mapped to "close document".
  23. Just a small request: now that the horizontal/vertical distribution options are no longer available in the toolbar and must be accessed via the top-level alignment drop-down menu, I was wondering if they could also be added to the right-click context-menu under the "alignment" heading? Currently, all the contents of the top-level alignment menu are available in the right-click alignment menu, except the distribution options. Thank you.
  24. The latest versions of OS X and iWork finally bring native RTL support to OS X, it would be greatly appreciated if there were some way to finally type in RTL with Affinity Designer. Please and thank you.
×
×
  • Create New...

Important Information

Terms of Use | 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.