Affinity Designer Customer Beta (1.0.19815)

[Andy Somerfield]

Purpose: Features, Improvements, Fixes

Status: Release Candidate

Requirements: Purchased Affinity Designer

Mac App Store: Not submitted

 

Improvements / Features / Fixes

 

- Further improvements to brush performance.

- SVG clipboard support (outbound).

- More Yosemite improvements.

- Fixed a couple of typos.

- SVG / PDF exports lines with pressure properly.

- @3x export fixes.

- Rasterise To Mask fixes / stability.

- Boolean ops stability.

[mannyhenri]

Was the export to EPS fixed?

[MEB]

Rasterize to Mask is much quicker now :)

[Davis]

Brush performance on Wacom tablet is amazing, great job!

 

Probably getting tired of my same posts :D, but the document size (https://forum.affinity.serif.com/index.php?/topic/1612-document-size-shows-wrong-on-retina-displays/&p=6569) bug still isn't fixed, that's one of the bugs that keeps me away from Affinity now.

[retrograde]

Looking forward to testing the boolean updates... cheers guys!!

[slv987]

I'm now getting a negative when I rasterize to mask.  Maybe I'm doing something wrong.  The last beta seemed to work correct.

[Andy Somerfield]

The last beta was wrong - white should be transparent.. 

 

I think everything else which turns intensity into opacity works like this.

 

A

[MEB]

SLV,

That's the correct behaviour. White is converted in a transparent area and black in an opaque one. Greys should let pass more or less depending on their value. So a dark grey will "filter" almost all the information from the object below (you should see a faint representation of what's below the mask), whereas a light grey will let pass almost all information, showing you a slightly faded picture of what's below the mask.

This is also now consistent with the way pixel masks work in AD.

[retrograde]

Booleans seem cleaner in my limited testing here, however there are still some extra unwanted points being generated... quite a few actually - see attached.

 

I did a quick test of 4 circles, I copied them, converted them to curves, performed a "divide" then pulled each piece apart.

 

--------------

 

Also I tested the expand stroke on a large stroke and a very small stroke (same stoke reduced). Same issues as before, the larger stroke is fine but the smaller stroke changed the shape somewhat, particularly in tight corner areas and on one end... - see attached.

[Dale]

Here's another example video of a geometry issue with Expand Stroke. This is (I believe) using build 1.019755.

 

http://recordit.co/UT396rtlEk

 

Reported via Twitter at https://twitter.com/paulmist/status/524300800755896321

 

The file in question: https://dl.dropboxusercontent.com/u/8821016/Affinity/gallery_slider_left.svg

 

At first I couldn't replicate because I drew my own similar shape, but using the SVG makes it clear.

[Dale]

Noticed when placing rather than opening this SVG that Convert to Curves is available on the right click menu (doesn't do anything), yet is greyed out in the Layer menu. 

[paulmist]

@Dale, thanks for posting that.

 

I'll follow up here.

 

To confirm, yes it was build 1.019755

[MattP]

Just want to mention to stop any reports of expand strokes issues that I haven't touched this yet - so everything will be just as it was in the Mac App Store version...

[fRED]

Speaking of boolean ops, will divide work on open paths at a point in future.

[fRED]

If i change an open document to portrait the margins disappear until i reenter the margin values in the document setup.

The margin values are rounded to full millimeters. 

 

And for german users it would be useful to have a comma as decimal separator. ;-)

[retrograde]

Sounds good Matt. I will refrain.  :)

[Smolli]

Hi,

 

the newest Beta still has problems with pdf-files, mainly with text which isn't separated like it should be. No problems with other apps, like iDraw so this must be AD-Bug.

 

I attached an example pdf. The text in the children should be all separated but are sometimes three in one text. Others are ok. I tried importing and exporting it with iDraw. iDraw does it correctly (all text separated) and exports correctly, but no change in AD.

 

Would be great if this could be fixed soon as this is rather important (at least for me :)) 

 

[JGD]

Hi,

 

I'm happy to see just how committed you are to this endeavour… Count me in for the betas!

 

That being said, here comes my first bug report:

 

CMYK value conversion from old .FH11 documents and colour parity with the Ai colour palette seems to be erratic at best. While I find small variations in interpretations to be acceptable, I found a flabbergasting bug in AD's colour palette.

 

In the first screenshot, you can see Ai's colour palette, editing a colour from a Freehand-generated .pdf. You can see that the colour values are r110g163b153, #6EA399 and c60m21y42k1.

 

Next up: ADs colour palette, editing the same colour, this time extracted from a .FH11 file. The same colour appears as r110g163b153, #6EA399, a slightly different c59m22y42k1 on the fields to the right of the CMYK sliders and a wildly discrepant c33m0y6k36 on the CMYK fields on the bottom right of the palette. Weird, huh?

 

Finally the third and last screenshot: I saved the original Freehand-generated .pdf back as a new .pdf in Ai, opened it in AD and got this colour palette. Now, CMYK values finally match those from .Ai (c60m21y42k1), but RGB values don't match anymore (r103g200b147 and #67C893). At least, now both CMYK fields show the same values…

 

By the way, this happens independtly of which colour mode I select on both Ai and AD, and also on the Ai .pdf import dialog that appears upon opening the old Freehand-generated file.

 

It also affects both the latest Beta (1.0.19815) and the latest stable version (1.1.0).

 

All things considered, what gives?

 

I'm also enclosing the affected files so you may assess what's gone wrong with them (the page where I extracted the colour from is page 2).

original files.zip

[JGD]

Hi again!

 

This time, I don't think this post counts as a bug report, but more as a commendation and collection of small suggestions.

 

I can't stress this enough: I LOVE what you're doing with advanced typography tools. While sparse, mostly text-based and semi-modal (I did mention earlier that dockable palettes are good, and your response back then was encouraging, so there's that, but in OpenType's case, not having that option isn't that big of a loss as it isn't a very frequently used feature anyway, even by typography buffs like myself; however, having a visual shortcut like, say, a button on the contextual toolbar, right next to Character, would greatly enhance its discoverability), I find your current list-based, no-frills, one-stop shop OpenType feature toggles way more intuitive than that “Figure”/“Position” drop-down menus, iconic toggles and nested menus crap from Adobe. Nested menus that go away if you miss your target are a PITA and, as far as icons are concerned, real typographers know their way around the terminology; even though icons may add a nice touch, in all fairness many advanced OpenType features are rarely used (and those that are the most common, like f-ligatures, are usually turned on by default)… On that regard, I'm divided about the usage of “Typography” label instead of the current “OpenType [features]”; is that a way to avert copyright issues with Adobe and/or Microsoft, or a deliberate decision to appeal more to old-timers? While I personally like the term “Typography” better, OpenType should be a more accurate label anyway (unless, that is, you're planning to add more features beyond OpenType on that palette; Apple Advanced Typography? AD-specific features?).

 

As for its usability, the palette is, as of now, sorely lacking disclosure triangles or, alternatively, a darker background and full “clickability”; I had a really hard time figuring out that I couldn't click the section names to expand them but had, instead, to click the [actually dark] “white” space to their right. I'd much rather have a tiny but identified UI target than a large, undefined one, but having both while better defining that visual hierarchy would be really swell. On the bright side, it's very nice to see that, unlike Ai's (which uses the graying-out technique) and AD's (which, bizarrely and uninuitively, “[brackets-out]” stuff), your Typography/OpenType palette shows/expands and hides/contracts according to the features supported by each font… That's a usability win, by my book!   ;)

 

As for the features themselves, I find it interesting, heartwarming and ironic that your OpenType support supplants even that offered by Adobe apps (I'm obviously referring, as usual, to CS6 and not CC; I'm not touching that with a 10-foot pole, not unlike most of your target audience, I'm guessing). I can't, for the life of me, get either Ai, ID or Ps to activate historical glyph alternates like the long s (ſ) even on Adobe fonts which were properly coded to support them, and always have to resort to the cumbersome (and inexplicably different from one another) Glyphs palettes (which AD seems to be missing, but that isn't even an issue at all because, unlike CS6, AD fully supports Unicode and pasting from the native and much more powerful OS X character visualization palette – HUGE kudos for not trying to pointlessly reinvent the wheel, guys!), which garbles the text upon copying and pasting from the generated .PDFs and changing it to a font which lacks the proper glyphs (AFAIK, one of Unicode's and OpenType's goals was the abstraction between glyph shapes and raw text data).

 

However… there's one little nit I must pick. The long s vs. modern s work[ed] in the exact same fashion as the current medial sigma (σ / “Greek small letter sigma” / U+03C3) and final sigma (ς / “Greek small letter final sigma” / U+03C2), meaning, the long s was the medial form (which was ultimately dropped a few centuries ago) and the final s was the final form (and, concurrently, became the standard, default form). As you can see in the enclosed screenshot, AD's default behavior when activating “Historic Forms Alternate” (a lovely and accurate label, if I may add, but maybe “Historical Forms” and “Historical Ligatures”, which are their official names as per the OpenType specification [ http://en.wikipedia.org/wiki/List_of_typographic_features ], would be even more accurate) is far from perfect, as all s's assume the medial form independently of their actual position.

 

Maybe that was an OT coding error on Adobe's part? I know, for a fact, that you can program contextual alternates to automatically choose the proper character, but I'm not really sure which feature takes precedence (I might as well test it later on in CS6 and AD with a font I was working on in Glyphs.app, which already has some contextual alternates coded)… Could AD perchance override such coding errors/OT idiosyncrasies and enforce a more sensible usage of Historical Forms, as per the second example on my screenshot (which had to be done by hand, by toggling off said feature on the final s's), or at least propose such a change to the powers-that-be (which are, heh… Microsoft and Adobe, I know)? By the way, I've tried it both on Adobe Caslon Pro Regular (Version 2.092) and Arno Pro Regular (Version 1.011) (which, interestingly, also used the OT “Stylistic Set 2” – a feature that, besides on AD and, I'm assuming, on APhoto and APublisher as well, can also be activated on ID, but inexplicably not on Ai or Ps – for the exact same function), with the same result. Just food for thought…

 

Anyway, big kudos for your Unicode/OpenType support, it seems to be shaping up pretty well! I must say I'm really impressed, and that all of this will become really handy in Affinity Publisher as well…  ;)

Medial vs final s.afdesign

[Andy Somerfield]

Hi JGD,

 

I've just fixed the CMYK inconsistency - we were failing to properly convert the CMYK values for the group of controls at the bottom right.

 

Thanks,

 

AndyS

[Dave Harris]

On that regard, I'm divided about the usage of “Typography” instead of the current “OpenType [features]”; is that a way to avert copyright issues with Adobe, or a deliberate decision to appeal more to old-timers? While I personally like the term “Typography” better, OpenType could be a more accurate label (unless, that is, you're planning to add more features beyond OpenType on that palette; Apple Advanced Typography? AD-specific features?).

 

Thanks for your comments. We decided "Typography" was a better name because the panel already includes some features outside of OpenType. For example, if a font doesn't itself any ligatures, but does define the Unicode characters for things like "fi", we use those characters to provide our own implementation of ligatures. We can get default implementations of quite a few features that way. We may implement Apple Advanced Typography in due course.

 

I agree we should rename "Historic Forms Alternate" and will do that in the next beta. The specification for that does not say anything about medial versus final forms; there are other features such as 'fina' that are sensitive about line ends but 'hist' isn't one of them. At the moment I believe what we are doing here to be correct as per the specification, and that if a font does provide 'hist', we should simply trust it. Is there a font that behaves as you prefer in other applications?

 

I agree it should be more obvious that Typography sub-panels can be collapsed. I'll ask Andy to have a look at that.

[JGD]

Hi Andy,

 

Great to hear that! And talk about a quick turnaround… ;)

[JGD]

Hi Dave,

 

Indeed, I didn't have time to ascertain whether those features were plain vanilla OT, AD-specific or a blend thereof, but something on the back of my head told me that the name change might be related to that… Good call, then!

 

As for your implementation of common ligatures, that does sound like a sensible approach. And even though OT is indeed an industry standard, it's nice to hear you're looking into AAT support as well.  :)

 

Hmm, you say the ‘hist’ feature doesn't support final and medial forms, even though there are some cases (the medial/final s being the most outstanding) where it could apply? I guess that may be a shortcoming of the spec itself and, thus (and since I'm all for following specs and standards), my suggestion of escalating that to those who define it in the first place may not be that farfetched, then?

 

As for ‘fina’, I'm guessing that is probably specific to scripts that require it by default [i just checked; arabic and syriac do], so maybe mixing and matching unrelated features may not be the best way to go when designing a font (or an application, for that matter)… But if it is the *only* way to do it, alas, I guess I'll have to bundle an instruction manual with my fonts (as for your side of the equation, well, it was just a suggestion for an ultra specific and rare use case, so if you really can't implement that, no biggie).  :P

 

Speaking of which: ‘calt’s of “long s_[space]”, “long s_[period]”, “long s_[comma]”, “long s_[hyphen]”, “long s_[em dash]”, “long s_[en dash]”, [etc.] pairs could also do the trick, I guess, but wouldn't that be a bit, pardon the pun, baroque?  :lol: [Also: wouldn't that only work with explicitly input long s, U+017F *characters* instead of subbed glyphs, which should really be rendered as proper long ‘s’s regardless of their surroundings?] Anyway, I'll also take this particular issue to other pastures (namely, the Typophile and Glyphs.app forums), as it seems interesting enough to warrant some further investigation and discussion.

 

You asked me about fonts that might behave in a more desirable manner in other apps; unfortunately, I didn't have much time to scour my work computer's font library, since I was doing it in between jobs. I mostly tested Adobe's own “Pro” fonts, but I'll be sure to check out that behaviour on other 3d party fonts and apps, and also on a font family I'm developing which, fittingly, has a gothic variant featuring medieval glyphs aplenty (I believe I haven't implemented the ‘hist’ feature yet, but now that you made me aware of it, I'll most definitely look into that; thank you for mentioning it). So, maybe that font will come from yours truly. ;)  Anyway, I'll let you know about my findings later on.

 

Well… As for the sub-panel collapsibility, my issue with it wasn't with finding out about it, but instead with reverting it. ;) That was the frustrating part, when I couldn't reveal one category after I accidentally (or was it deliberately, as a UI stress-test?) collapsed it, even though I was frantically clicking on its name tag and expecting it to work. So, even if you don't add a disclosure triangle, just having the whole sub-panel header rectangle be clickable would make the UX that much more friendly, IMHO.

 

I guess that pretty much sums it up for now… Good conversation we're having here; I'm really glad that you care about typography as much as your company's name implies.  ;)

[slv987]

SLV,

That's the correct behaviour. White is converted in a transparent area and black in an opaque one. Greys should let pass more or less depending on their value. So a dark grey will "filter" almost all the information from the object below (you should see a faint representation of what's below the mask), whereas a light grey will let pass almost all information, showing you a slightly faded picture of what's below the mask.

This is also now consistent with the way pixel masks work in AD.

I've attached a video link below.  My black is not opaque.  It turns transparent when the mask is made and the white takes on the color of the object below it.  I guess I was under the impression that this was the solution for making a 1-bit tiff transparent and changing it's color.  Let me know if I'm off base here.  Both Freehand and Illustrator you can bring in a tiff and the white is made transparent and the black you can change to what ever color you like.  When importing an ai file AD actually handles this correctly as shown in my video in the Questions forum.  Sorry to be a pain.  I really appreciate all that you guys are doing.

 

https://www.dropbox.com/s/s9g5cyt4nty44sh/Tiff_Transparency.mov?dl=0

[Smolli]

Hope the pdf-import bug hasn't fallen through.