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

adamtwar

Members
  • Posts

    27
  • Joined

  • Last visited

Recent Profile Visitors

1,154 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. 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.
  8. @Dave Harris Congrats for implementing optical bounds. There are indeed very few fonts that have it, but there were also hardly any apps to support them, and there was never a good UI in a font editor that would help people design them. But this may change. Question: when reading the font, do you check for explicit presence of the 'lfbd' and 'rtbd' features, or do you only check for 'opbd'? (I think 'opbd' is somewhat stupid and not needed — 'lfbd' and 'rtbd' should be sufficient.)
  9. 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.
  10. How do I hide those violet rectangles (bounding box indicators around objects?)
  11. The text capitalization feature (Typography palette / Capitals / All caps or Format / Character / Capitalization / All caps, but also the non-OpenType small caps) seems to work only on ASCII Latin letters, which is how it used to work in apps in the 1980s :) See screenshot attached. Not even Western accented characters are capitalized. But the commonly-used text internationalization libraries such as ICU and even the freely-available Unicode Standard data tables provide the correct case conversion routines (which should be done in a language-sensitive way to take cases such as Turkish or German into account). Even OS X by itself provides appropriate mechanisms (- (NSString *)uppercaseStringWithLocale:(NSLocale *)locale ). Best, Adam
  12. In the release notes for Affinity Designer Customer Beta (1.0.19988), you say "Implemented OpenType GPOS support". Could you be more specific? I just tested Arial Version 5.01.2x with the text "ną̊́n" (U+006E U+0061 U+030A U+0301 U+0328 U+006E), which utilizes the font’s built-in "mark" and "mkmk" GPOS features, which should normally be on by default. Here is an image showing how the text is rendered in Affinity Designer, Apple TextEdit (OS X 10.10), Microsoft Word 2011 and Adobe Illustrator 2014.1. As you can see, in all the apps except Affinity Designer, the diacritical marks are attached at their correct positions, thanks to the GPOS positioning done by "mark" and "mkmk". In Designer, it looks like the GPOS features are not at all applied. Regards, Adam Twardoch
×
×
  • 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.