Jump to content


  • Content Count

  • Joined

  • Last visited

About adamtwar

  • Rank

Recent Profile Visitors

323 profile views
  1. Whether this is overstated or not is a matter of personal scale. I instantly notice whether text was set using software that implements concepts developed before my great-grandfather was born (Affinity or Microsoft are effectively doing what Mergenthaler’s Linotype machine was doing in the late 1880s), or perhaps whether it used concepts developed around the time I was born (the 1870s Knuth and 1980s Karow and Zapf work). Neither concept was great. When Knuth developed TeX, computers could deliver computer graphics like those simple lines seen on the screens in Star Wars. Today my phone can render realistic 3D environments at 60 fps, yet new products aimed at professional publishing deliver 19th-century quality of text composition. I know it just means that primitive text composition is simply good enough for most, and therefore there is no need to innovate. But it’s sad. After all, world literacy has grown from 40% in the 1970s to 95%, and as many people today have internet access today as there were people on Earth when Knuth developed TeX. Nearly twice as many people have smartphones today than could read in the 1970s. So a multi-billion audience and zero innovation. Oh well.
  2. No, I don’t. But I do think that with today’s computers, developers of new apps could opt to implement text composition based on the work from the 1970s and 1980s (Knuth, Karow, Zapf), and not just the 1880s (Mergenthaler).
  3. Every single page of a simple novel typeset in Affinity Publisher will look vastly inferior to the same novel typeset with the same fonts on the same page dimensions in InDesign. Basically it's a difference between playing on a piano in a bar and on a concert grand piano. Both can emit principally the same sound but only one sounds good enough to be on a studio recording. Any publication that has even a brief portion in a non-European language (any Asian or Middle Eastern language) will fail in Publisher unless you use a different app to typeset the non-European portions. Any publication that uses longer paragraphs of justified text will naturally look much worse when made in Publisher than when made in InDesign — a school or university text book, a collection of essays, a scientific journal. The cost of the page layout software is often relatively minor compared to other cost of creating a quality printed publication (the printing itself, paper, distribution). Choosing Publisher over InDesign may be dictated by the fact that Publisher is cheaper — but it also obviously produces inferior results. (This is not so with Designer or Photo — there, a skilled user may produce very high-quality output, and the apps are in many aspects better and more usable than the Adobe counterparts.)
  4. I agree that creating an app of such complexity as Affinity Publisher is a huge task, and no matter how large your team is, you have to prioritize. But implementing proper typography is a tedious task, and requires not just engineers who know how to code but also people who know what exactly should be coded. Quality typesetting is not just a matter of implementing some “algorithm” (btw, the Knuth algorithm is very old and does not work well is quite a few languages). This also requires research. Publisher lacks even basic support for most writing systems and languages of the world, and I guess adding that might be a higher priority than increasing the quality of support for Western languages. But overall, it does look like AP is an app for leaflets and simple magazines. It is not an app for people who do serious text publishing. Perhaps in a few years this is different, but today Affinity Publisher is not much of an alternative for InDesign, except for a specific segment of uses of InDesign.
  5. The glyph scaling is only a minor aspect of the Adobe InDesign paragraph composer. When an app typesets a paragraph, it can employ whitespace justification (narrowing or widening of spaces between words) and hyphenation in various degrees. The same paragraph can be typeset in many different ways. InDesign, and also TeX/LaTeX, compose paragraphs in such a way that the whitespace change across all lines of the paragraph is minimized. Primitive linebreaking apps such as Microsoft Word, Apple Pages, Affinity Publisher or web browsers don’t do that. They just go line-by-line, find the first hyphenation point of a word that overflows, break there and then justify the whitespace. Then they go to the next line. So in Publisher, you may end up with a paragraph where one line has huge word gaps and the next line has tiny word gaps, and then some lines again have huge or tiny word gaps. In InDesign, the word gaps within the entire paragraph are more evened out. On top of that there is the glyph scaling. Affinity Publisher at this point is of Microsoft Publisher/Serif PagePlus quality. It’s vastly inferior to Microsoft Publisher in supporting different languages. Affinity Publisher is only useful for typesetting simple documents in a handful of languages. Comparing it to InDesign at this point is like comparing a Fiat to a BMW This, btw, is not necessarily a bad thing. There was a market for a simple page layout app. But this is a completely different class from InDesign.
  6. The Czech Hunspell dictionaries (and publicly-available Hunspell dictionaries for many other languages) are licensed under GPL. https://github.com/LibreOffice/dictionaries/blob/master/cs_CZ/README_en.txt As a software vendor, you cannot distribute GPL code together with proprietary apps. I imagine licensing is the reason why Affinity does not bundle many spelling and hyphenation dictionaries. Each of them has different licensing terms and it’s quite difficult to harmonize them.
  7. I found it. View / Snapping Manager / Show snapping candidates. The most absurd UI place ever (why not in the View menu directly?), and it's just plain wrong to have it on by default.
  8. How do I hide those violet rectangles (bounding box indicators around objects?)
  9. I have a MacBook Pro (Retina 15 inch late 2013) with Mac OS X 10.11.2. I have a non-Retina monitor connected to the Mac, so I have a Retina and a non-Retina screen. It seems that Affinity Designer has a problem with it, because regardless of which monitor I move AD to, all the contents of the canvas is rendered in non-Retina mode. I have the Vector mode active in AD. I'm attaching a ZIP with sample AD drawing, and screenshots of the document open in Affinity Designer 1.4, and also copy-pasted from there to Sketch 3.4.4 and to Autodesk Graphic 3.0.1. Both Sketch and Graphic correctly update the pixel density when I move the app between the two screens, so on the non-Retina, the LoDPI mode is used and on Retina the HiDPI mode is used. But in AD, when I move the app window from non-Retina to Retina, all the panels are correctly updated to HiDPI but the canvas contents stays in LoDPI. 151212-affinity-designer-retina.zip
  10. Dave, Thanks for your reply. I just checked Gabriola version 5.92 (included in Windows 8.1), and 1/2 with "Contextual Fraction Forms" produces the correct ½. Which version of Gabriola do you have? Perhaps Microsoft fixed this already. Bugs in fonts are bugs in fonts. End-user apps shouldn't try to fix bugs in fonts. Users should report bugs to font vendors, and the fonts will be fixed. The right person to report bugs in Microsoft fonts is Simon Daniels <simonda@microsoft.com> All the best for the custom OpenType Layout implementation :) Unfortunately, this somewhat cools my hopes that the Affinity suite will be useful in the multilingual context. :/ Getting Indic or even Arabic shaping properly using custom code is not for the faint of heart. Best, Adam
  11. The point with fractions is: if the font has the "frac" feature, then it means that the type designer has "dealt with the notion of fractions". If the font has the "smcp" feature, it means the type designer has "dealt with the notion of small caps". Introducing a hybrid handling of OpenType + Unicode substitutions may actually break a carefully-engineered "smcp" or "frac" implementation in the font. For example, some fonts may have code that relies on contextual logic which will interpret a string such as 11/256 and will rely on the fact that all the glyphs are there in the string. If you do 1/2 -> ½ before, then the contextual implementation in the font may break entirely. Same goes for ligatures. Some fonts have mark positioning or special handling for Turkish language or some contextual smartness implemented in "liga" in conjunction with other features. If you do "f i -> U+FB01" on the Unicode level beforehand, the subsequent OT logic in the font may break. The fallback Unicode-based replacements (ligatures, ordinals, superscripts, subscripts, fractions) should be only done if the respective features are not in the font. In essence, the Unicode-based fallback implementations can be seen as "synthetic OpenType" — any sane font developer would have implemented them using OpenType in the same way, but some fonts do not have OpenType Layout features, though "they might have had them", and you're simulating that using Unicode-based substitutions. But if you start mixing these things (OT and Unicode), you'll definitely break stuff in most of the ambitious OpenType fonts such as Cambria or Gabriola or EB Garamond. With superscripts and subscripts, it's even more complex than that. You have three possible ways: 1. The fake way: you just scale all glyphs and shift them up (like in Microsoft Word). That works for all glyphs but is graphically inferior to any other solutions. 2. The Unicode way: if there is no "sups" or "subs" features in the font, you do Unicode replacement of digits and some letters with U+00B9, U+00B, U+00B3 and U+207x if they're present in the font for superscripts, and U+208x and U+209x for subscripts. 3. The OpenType way: you just execute "sups" and "subs" blindly and don't do anything. My view is that in the OpenType panel, you should only use method 3 if "sups" or "subs" are present in the font, and if not, you should use method 2. In Format / Character / Baseline, you do have Superscript and Subscript, and they use method 1. This is how it should be, so it should stay that way. The hybrid small caps approach is really practically not needed. 99.9% of the fonts that have "smcp", will have it for all the relevant glyphs. So if there is "smcp", you should just use that. If there is no "smcp", only then you should do fake small caps. There are literally like 10 or maybe 100 font families out of 50,000 which have "incomplete small caps", i.e. they have more lowercase letters than small caps glyphs, which means that some lowercase letters are not being small-capped when "smcp" is applied. But this is really a tiny fraction, and I think this should be disregarded. You're right to guess that the hybrid approach would make the text appear inconsistent. Also, keep in mind that some "smcp" feature implementations involve additional features such as "ccmp" and "mark": the lowercase letter "á" goes in, it's decomposed in "ccmp" by "a" followed by the combining acute, then the "a" is replaced by a small-cap "a", and then in "mark", the combining acute is positioned above the small-cap "a" accordingly. So there is no single-glyph "small cap á" in the font for good reasons. So if you do a hybrid approach and uppercase "á" to "Á" and then scale it down, you'll break things. I still don't see why you wouldn't want to unify the "Fraction ligatures" UI entry with "Fraction". They do the same thing, just using two different levels: one does it on the Unicode level, the other on the OpenType level. It's the same thing as what you do with "Ligatures" — you either do "liga" or U+FB01. Sorry to hear that your support for OpenType Layout is GSUB-only. Do you use CoreText or ATSUI, or HarfBuzz, or some custom code? If it's custom, then, oh my... You'll be in trouble :) Good luck on fixing the bugs and on implementing GPOS (starting with "kern"!) Affinity Design is a cool product. I hope it'll also turn into a very useful tool for typographically-aware designers. :) Best, Adam
  12. 1. Download and install: https://bitbucket.org/georgd/eb-garamond/downloads/EBGaramond-0.016.zip 2. In Designer, with Artistic Text tool, type "The quick brown fox 0123", set the font to EB Garamond and select the whole line. 3. Open the OpenType palette. 4. In Capitals section, choose "All Small Caps". The text will change to THE QUICK Brown fox 0123 i.e. the small caps are only applied to some letters and then no longer. Disable All Small Caps. 5. In Figure Style section, choose "Lining". Only the digits "01" will change to lining while "23" will stay the same. If I use Minion Pro instead, "All Small Caps" will turn "THE QUICK BRO" into small caps and the rest of the text will be unchanged, and for Old Style figures, also only 01 will be changed. So this behavior is not font-specific. Best, Adam
  13. In Affinity Designer, in the Format / Character / Show Character dialog, there is a Language dropdown list. On my computer, it lists: * None * Invalid * English * Polish (Poland) * German (Standard) * Spanish (Spain) * Russian Could you answer: 1. What exactly does this selection influence? Spelling? Hyphenation? OpenType "locl" feature? 2. If Spelling and Hyphenation — which engines does Affinity use for it? 3. How exactly is this list populated? I cannot figure out why my installation has these particular entries and others are missing. More clarification would be appreciated. Regards, Adam
  14. For some reason, two of my threads I started here got deleted. One was that in the OpenType palette’s title, it says "Open Type". That’s incorrect usage of the trademark and font format. "Open Type" was also used in one of Serif’s e-mails. Please always use the correct term, "OpenType", without a space. The other was more of a question, perhaps filed incorrectly in the Bugs section. But why was it deleted?
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. 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.