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

mqudsi

Members
  • Posts

    166
  • Joined

  • Last visited

Posts posted by mqudsi

  1. 28 minutes ago, walt.farrell said:

    If you have a sample PDF that works "properly" in Illustrator, and doesn't work in the Affinity applications, it might help if you provided it so we could examine it.

    I've already attached it to the first post :)

     

    Quote

    OK, but we know that Illustrator plays "games" like embedding its own proprietary data in EPS files that it exports. Do we know that it does not do that with PDF files that it exports?

    I'm assuming it does do just that.

  2. 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?

  3. 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:

    image.png.815d863e5dfc54581ce87c0d10db1954.png

     

    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):

    image.png.42209f6663d5b8c19bc5e397a4d8f94a.png

     

    (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.

  4. 7 minutes ago, LibreTraining said:

    Based on this and a few other posts, it appears that Adopy may be embedding some sort of non-standard data in their PDFs which may enable them to round-trip OpenType features.
    BUT, simply displaying the embedded small cap glyphs when the PDF is opened in IL does not mean they are doing this, it may be they are just displaying the outlines that are there.

    What happens if you insert a cursor and start typing lowercase text?
    Does it display as small caps? (that would be evidence that the OT feature is still applied).
    If you can copy small cap text from this exported-and-re-opened-in-IL PDF, and paste it into a text editor,
    and it appears as lowercase - that would be evidence it is still lowercase.

    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. 

    9 minutes ago, LibreTraining said:

    Both of these would point to something non-standard going on.

    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.

    10 minutes ago, LibreTraining said:

    Because as I mentioned above, the underlying code points embedded are uppercase.

    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.

  5. 40 minutes ago, walt.farrell said:

    You're right; I should have been able to figure out that you must have the font itself.

    However, PDF files do not (as far as I know) support "text properties". They describe what fonts are being used, and tell you what code points or glyphs are being used, and contain glyph tables. They do not (again, as far as I know) have a concept of "small cap".

    This often turns up as a problem in an Affinity application in a different way, when someone uses Affinity to export a PDF and sets (or leaves the default) option to "subset fonts", and then tries to Open the PDF again with their Affinity application. With only a font subset available, there is insufficient information to properly handle and recognize ligatures.

    The solution (when exporting from Affinity) is to include the full fonts. Then the glyph tables in the PDF have appropriate information and ligatures can be recognized.

    If I had to guess, since PDFs do not know what a small cap is, the same would apply to exporting PDFs from Affinity if the document used small caps. Just like ligatures, Affinity probably wouldn't be able to read the small caps properly if the fonts were subsetted in the exported PDF.

    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?

    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). 

    25 minutes ago, Old Bruce said:

    If you copy the text it is all uppercase. For small caps to work there needs to be uppercase and 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).

  6. 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):

     

    image.png.a6060a89f4c1fc4ec4357e99162b0bf3.png.dd4adddafe65d5ace354cc0b7defd077.png

    vs here's what the resulting text from the exported PDF looks like when viewed in any PDF viewer:

    image.png.bf0ce0f829b58f86ac5b95263cc9ab9b.png

    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):

    image.png.d23a4ae0427a72474c985ed609fd0880.png

     

    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:

    image.png.ce6f0d85555b93e081b258e4f38e94b8.png

     

    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

    image.png

  7. 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

  8. 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:

     

    image.png.891866ef523a48680b0082e8eac38794.png

     

    The resulting PDF is not correctly imported; here is an example:

     

    What it should look like:

    image.png.0b241dbd51361715187acd2a4f93cd2a.png

     

    What is displayed in Affinity Designer 1.10.4 when the PDF is opened (without selecting "favor editable text over fidelity"):

    image.png.cafc014da984d346fa49a6934ed0de21.png

     

    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:

    image.png.0dcf0379e42876d0016b79c68bbe5c29.png

    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:

    image.png.e9d88ca0fa4a12471cf5247cdccc10a0.png

     

    I've attached the actual PDF exhibiting this incorrect behavior as exported by Adobe Illustrator (i.e. without any corrections from Affinity Designer).

    image.png

    Fundraising Dinner 2021 - Web.pdf

  9. 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.

  10. 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.

  11. 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.

  12. 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.

×
×
  • 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.