Category Archives: Design

ars technica: How QuarkXPress became a mere afterthought in publishing

Quark’s demise is truly the stuff of legend. In fact, the story reads like the fall of any empire: failed battles, growing discontent among the overtaxed masses, hungry and energized foes, hubris, greed, and… uh, CMYK PDFs. What did QuarkXPress do—or fail to do—that saw its complete dominance of desktop publishing wither in less than a decade? In short, it didn’t listen.
ars technica: How QuarkXPress became a mere afterthought in publishing

Much of what happened to Quark and Microsoft is now happening with Adobe. I am increasingly seeing criticism of Adobe’s painfully high prices for questionable updates (primitive 3D objects in Photoshop? Why?). The difference this time, however, is that there is no alternative on the horizon. If I recall correctly, InDesign was rumored for quite a while before release. Even if InDesign ended up being vaporware, the enthusiasm was palpable but Quark appeared to simply not give a shit what anyone had to say; Quark’s hubris was just astounding. Today, Adobe has deaf ears if only because they have no compelling reason to listen.

Why I rail against Adobe: I care.

Pretty much all of my blog posts about Adobe are critical, if not outright negative. This is because I care about the environment in which I work. My line of business, I am all but compelled to work with Adobe products. They are a major focal point of my development efforts, and are something with which I have had a relationship for over twenty years now.

Publishing technology has few alternatives. Before InDesign, QuarkXpress was the dominant application for page layouts. When InDesign CS2 was released, a gust of fresh air blew into the state of page layouts, and Quark quickly was given a run for its money, quickly outpaced by InDesign’s innovations. There were others, like PageMaker and FrameMaker, but they had their specific markets and requirements that generally didn’t meet book publishing’s general needs with the same ease as Quark and InDesign.

For a case in point, one need only look at the link manager in both applications. A “link” in this case is a piece of art placed into pages, or an XML file used to populate a template. A lot of time has passed since I worked with Quark in depth, but I remember Quark’s link manager being very linear with a poor UI and file selection UX. InDesign’s link management became everything that Quark’s wasn’t and kept innovating. The link manager is not “sexy” in the sense that it is an easy-to-implement, eye-popping effect for a client to see, but it is a focal point in the application for the page builder, who has to manage anywhere between a handful to thousands of links in a single job. A designer cannot build a design without using the link manager; it is like needing food to survive. With Adobe Creative Suite 4, my company made the decision to have all new titles be made in InDesign and have yet to change that policy. I learned how to script on that version and have built up a substantial library of code since.

Recent releases of the Creative Suite, and the newly released Creative Cloud, have left me wanting for better Applescript support, to the point where much of my code is going to be rendered obsolete within a year at the rate things are going. In my team’s recent purchase of Quark licenses—purely for legacy file support purposes, sadly,as we have a soft spot for Quark since some of us built are careers on it—the link manager was the first feature we looked at. It was immediately apparent that their link management had not changed one iota since InDesign’s first release, and quickly went back to work with InDesign, disappointed that nothing new was on the horizon for us.

There is one promising open source page layout application, but since scripting support appears to be even more dodgy than InDesign’s, there is no point in even downloading the application. “Contribute to the project,” you suggest? Noble, but there is no way I can fit in free development work in between The Day Job, school (I get 10-20 hours of homework each week), and family. So, I keep slogging with InDesign.

With Photoshop and Illustrator, things are more promising with there being a number of good alternatives, but without that page layout to tie it all together, I have to pick my battles elsewhere. I’m really not keen on supporting whatever arbitrary language a given application supports in addition to Applescript and Javascript. Wrangling those two is enough work as it is.

Really, the only way I can get out from Adobe’s mire would be to change my careers away from anything remotely design-related, which wouldn’t be all that bad, but that would really mean changing industries, which is something that is, personally, unappealing to me for the time being. I have my reasons, but this is not the forum in which to discuss them.

What this means is that, in the end due to industry and personal constraints, I cannot avoid Adobe, and will not be able to in the foreseeable future. While I am here, working with their apps, I have a desire to see them improve, or at least be better maintained. Adding in 3D object creation into Photoshop is not what I consider a good use of anyone’s time. So, I criticize.

Adobe’s Applescript API: Their near lack thereof.

I have this working draft of a post explaining how badly broken Applescript is from purely an Apple-owned technology perspective, and imploring Apple to do something about it. It’s a bit long. But, since Adobe’s Creative Cloud has been released and I got my grubby little hands on a copy, I decided to look at the state of Applescript support in my most-used applications. It’s not that I have high hopes of anything improving given support since Creative Suite 5, but this is my bread and butter so it’s worth a look to see what I have to workaround in future upgrades of scripts, if upgrading a script is even worth the time.

Currently, my Applescript “support” of in-house that utilize Adobe applications has been relegated to using one call—doJavascript:withArguments:showDebugger: within the Scripting Bridge header, if one can be generated. (As I explain in my as yet unfinished post) Adobe’s Applescript support is rather dodgy in its implementation—there are some long-standing, show-stopper bugs (I’m looking at you open command in Photoshop—so I thought it best to migrate over to their Javascript APIs. Interfacing with other applications like Excel and a couple others of my own devising centered around XML parsing is paramount to my workflows.

Here is what we have to work with.

  1. Photoshop: Line 1280.
  2. InDesign: Does not exist in the header.
  3. Illustrator: No header could be generated because the sdef (scripting dictionary) file does not exist.

I took a look at some other apps, like Bridge, and things go generally downhill from there. Essentially, any Applescript-related support is rendered useless in Creative Cloud. This is infuriating, back-stabbing bullshit. I would also like to say this is also unacceptable but that would ring hollow since the state of publishing technology is such that I have no choice but to use Adobe software. Nowhere on their site do they formally announce the drop in support in Illustrator, and given the dodgy performance of their Applescript API.

I wish Adobe would do three things:

  1. Formally announce that Applescript, if not OSA support in general, is going away.
  2. Pick a date well in advance (like a year) for developers to prepare.
  3. Turn it off all at once so I can stop having to hunt for the state of their API.

This unannounced erosion in API support by inconsistency is poor form, though I expect nothing less from Adobe these days, and reflects their general customer support as well.

Adobe’s Security Breach

From Adobe’s blog (emphasis mine). . .

Our investigation currently indicates that the attackers accessed Adobe customer IDs and encrypted passwords on our systems. We also believe the attackers removed from our systems certain information relating to 2.9 million Adobe customers, including customer names, encrypted credit or debit card numbers, expiration dates, and other information relating to customer orders. At this time, we do not believe the attackers removed decrypted credit or debit card numbers from our systems.

The issue of these major security breaches are really starting to hit home, and I will likely review my own security standards for the family in the near future. I use Adobe products much more than I ever did LinkedIn, and I get tremendous value out of Adobe. Hell, my career universe has Adobe products firmly at the center. Luckily for me, my Adobe purchases are managed by my company so there is no direct financial risk for me, but there is only so far one can get with their software without at least an Adobe ID.

This does bring to bear a challenging implication about their new subscription model with Creative Cloud. When Adobe writes “At this time, we do not believe the attackers removed decrypted credit or debit card numbers from our systems” there is an implied “yet” in that statement based simply on the fact that they now store financial information on their servers until told otherwise by customers due to the new subscription service.

I don’t want to imply that Adobe doesn’t take security seriously, but with the amount by which they are effectively raising their prices (read as: more than doubling their annual cost) and with the responsibilities that Adobe voluntarily took on by requiring thousands, if not millions, of people to store their financial information on their servers, customers should get better services than this.

2.9 million. I await my email from them.

UPDATE: I got an email for a long-forgotten account. Joy.

UPDATE: BBC: Adobe hack: At least 38 million accounts breached. Joy.

Slant.com: What are the best programming fonts?

Slant.com: What are the best programming fonts?. (via Hacker News)

The actual voting is likely not very scientific, but this is a really great collection. I’m a bit surprised to see that (a) Source Code Pro is at the top (by a thin margin) and (b) there is no italic form of the font. That latter point is a glaring and non-starter omission for me as I change all my comments to italics to help with reading context, and doubly so since this an Adobe font, a world leader in font development.

I had forgotten about Anonymous Pro, which I liked for a while, but I thought the glyphs were too wide.

I am currently using Menlo and really like it, particularly at 11 pt. Most of my editors default to Monaco, which I never liked. Monaco always just seemed a bit too clunky for my taste.