1 feature (greyscale export) exclusively added for Print; 6 features exclusively added for interactive & tablets

...

Adobe does need to make sure they are up to play in the tablet publishing market, but that does paint a pretty clear picture that they aren't putting much effort into the print side which is probably 70-90% of InDesign's userbase.

I don't think that's a fair analysis. Print is much mature, it requires far fewer features to be added to reach functionality.

I agree they're putting more effort into non-print areas, but print does not require large amounts of effort.

I'm not sure how you analyze it,but I think the above is not really fair.

I dunno, I think most print customers are happy and don't need very much, and the general feature additions and bugfixes will keep us happy (that's not the same as "static"). Those struggling under the thumb of endnotes are in a different situation, but they're definitely not a plurality of print users.

That is fabulous!

Bob

Well since 2008 - most features have been heavily tipped towards Mobile.

Can't really see huge improvements to long document features since then - one can only assume that Adobe has no intention of developing that area of the Software anymore (it has been 4 years).

Looking back through the new features - there are somethings that would/could help speed up production. But nothing that I can't already do. As a print driven person using InDesign - the new features of CS6 don't really appeal all that much to me personally (and possilby a million other users).

One has to ask - why should a million print designers and/or companies bother upgrading to CS6, when they can do all the things already required with even CS3 or CS4 or CS5/5.5?

There really hasn't been any great enhancements for print designers since CS3 - so why should Print Designers/Companies bother upgrading?

Stix Hart wrote:

 

Well, I'm glad that everyone listened to my request to "not moan about endnotes ommision"!  And kept to my topic of what the new donut is...!

 

Well to answer your question - the biggest "donut" was to put all their resources into making it more towards Mobile user orientated software than addressing the needs of their Print users - since 2007.

I think though - seriously - it's the fact they keep adding Nodes to frames - I think it might be a bit daunting for a newbie.

Anchor node

Lock node

Corner node

Content nrabber

and now - The Link node

Maybe they simply misread our complaints.

"They asked for footnodes and endnodes, but now they are still complaining!"

Alas, it sounds like they do look at the Feature Request forum:

The "Improve Footnotes Please" thread has had 2,376 views in 2 years; "Export to Gray" has had 13,221 views in virtually the same period.

I haven't searched for how many asked for a better content collector, but to be fair, no-one ever "requested" GREP styles either and I dearly love them.

Who knodes Jongware, who knodes?

Eugene Tyson wrote:

 

One has to ask - why should a million print designers and/or companies bother upgrading to CS6, when they can do all the things already required with even CS3 or CS4 or CS5/5.5?

 

There really hasn't been any great enhancements for print designers since CS3 - so why should Print Designers/Companies bother upgrading?

Well, I'm a print designer, as I said, and I mostly don't need footnote/endnote functionality, so that's a minor inconvenience to me (but I definitely support improvement for those of you who use them every day), but I can say without hesistation that CS5 is miles ahead for me in productivity over CS3. I still work in CS3 for one client and it's a pain.

I happen to prefer CS5 to CS5.5, but if I did a lot with anchored objects I'd probably feel differently. Grayscale export is probably the one thing that would get me to make the move to CS6 for my workflow, but it's not life or death unless I decide to start doing ePub.

Eugene Tyson wrote:

I think though - seriously - it's the fact they keep adding Nodes to frames - I think it might be a bit daunting for a newbie.

 

Anchor node

Lock node

Corner node

Content nrabber

and now - The Link node

I'm not a newbie, and that's possibly the thing I dislike the most about the new version -- UI clutter.

Peter Spier wrote:

 

Well, I'm a print designer, as I said, and I mostly don't need footnote/endnote functionality, so that's a minor inconvenience to me (but I definitely support improvement for those of you who use them every day), but I can say without hesistation that CS5 is miles ahead for me in productivity over CS3. I still work in CS3 for one client and it's a pain.

I do require better footnoting - especially where footnotes fall inside a Table - and I most definitely need the ability to span the columns with the footnotes.

That aside, there other long document features I don't use that often, like Indexes and complex TOCs - but I do see a need to improve on them.

Cross-references can be used in both print and mobile

Indexes can be used in both

Complex TOCs can be used in both

Working with Markers

Book File - could have massive improvements

Footnotes don't even fall into the category of Long Document features - it's simply a feature that was introduced and not improved on.

An improvement [enhancement] to any of these features would be welcome and benefit both the Print and Mobile market.

I happen to prefer CS5 to CS5.5, but if I did a lot with anchored objects I'd probably feel differently. Grayscale export is probably the one thing that would get me to make the move to CS6 for my workflow, but it's not life or death unless I decide to start doing ePub.

I have to admit - the Anchor Object node is very nice in CS5.5 but it lacks functionality. Yes it's functional, but the way I did anchored objects in CS5 was to Anchor one object, create the object style - then anchor objects and apply the Object Style.

This made it very easy to adjust the Anchor in the Object Style.

CS5.5 you drag the node to where you want to anchor - done - I've already started to forget to create the object style. Thus - globally changing the Anchor because a problem if needs be.

Begs the question, would new users be aware to create an Object Style for their anchored object - and also - if you do create a Style for an anchored object - shouldn't you be able to specify that all Anchored objects be given this Style when you drag a node to an anchored position?

I haven't spent enough time working in CS6 for real to draw an opinion, but I'm definitely skeptical of my (and others') ability to guess how much they'll be affected by UI changes, and to know how much we'll habituate to them.

But it really doesn't matter -- the only way new features will be seen by the critical mass of users is if they are on by default. So even "bad" new features ought to be turned on visibly by deault, unless they have a hugely hugely negative impact. I can't imagine a world where a new link badge is hugely hugely negative (but I can easily imagine it being annoying for everyone).

So I definitely support this stuff being turned on by default, if it gets added to the product.

I suppose I'm also influenced by how easy it is to figure out how to turn it off.

Empirically, users had a lot of trouble figuring out that the Content Grabber was turned off with "View > Extras > Hide Content Grabber"; in part because nobody knew it was called that.

Given that the Link Badge actually looks like a chainlink:

I'm optimistic users will have an easier time turning it off ("View > Extras > Hide Link Badge") than they do the Content Grabber.

Perhaps that's naive?

Only real testing with real users will tell...

Grayscale export is probably the one thing that would get me to make the move to CS6 for my workflow, but it's not life or death unless I decide to start doing ePub.

Would you really trust an automatic grayscale function to convert your layouts?
Jay

Depends on what the document is. One scenario would be for replacing the current workflow where the student newpaper I advise currently print to postscript and distill because we can't be sure that all of the ads we get will be grayscale, nor do we have a staff that is necessarily capable at any particular time of converting photos prior to placing. ID's conversion will be as good as Acrobat's or Photoshop or Illustrator's un-tweaked conversions, and you can pick an output profile, so for non-critical stuff, why not?

Non critical and un tweaked being the key words. I tried the print to file with a b&w driver once (back in the pagemaker days), and had a nice red, green and blue pie chart turn into an unrecognizable blob of grey. Ever since I've always done custom conversions in Photoshop for grayscale photos, plus whatever needed to be done in ID and Ill.
Jay

Why not? We trust it to convert RGB to CMYK.

Bob

A bigger difference in gamut, rgb is a lot closer to cmyk, than it is to grayscale.

Jay

There are also workflows wher everything is already grayscale and users want to export a true grayscale (one plate) PDF, with an embedded grayscale profile. I expect that will be a more common usage.

This is a reproduction of my pie chart example, turned to grayscale automatically (in Illustrator).

After receiving multiple rgb ads for what was supposed to be grayscale, I can see Peter's usage, although I fix those when I receive them.

Jay

Here's is an RGB chart created in InDesign CS6. The pie segments were 255R 0G 0B, 0R 255G 0B and 0R 0G 255B.

Top is the original in screen capture from InDesign.

Bottom is by choosing View > Proof Setup > Custom > Dot Gain 15%

Out of curiosity try

R  151  40  46

G  51  163  87

B  51  52  255

Jay

Large text only publication with Crop Marks will trigger registration (use of CMYK) to create the crop marks - which always trigger the filter at our printers when they run it through their preflight.

We get urgent messages "Your Layout is CMYK please FIX!!!!"

And in reality it's just the crop marks.

Here you go — Your RGB Values:

Gray preview - 15% Dot Gain setting

Not the same values, but pretty impressive, it looks good for a quick and dirty conversion. I'll still stick to the black and white adjustments in photoshop, and manual adjustments elswhere for the critical jobs.

Jay

Absolutely - for critical jobs it's important to adjust the image in B/W and not really on an automatic conversion.

I do very similar things for critical jobs in print full colour - it requires a lot of treatment to images in photoshop before placing and creating pdfs.

But for quick and dirty jobs, a CMYK conversion of the RGB images placed in the document is ideal - and much quicker.

Different workflows etc.

Anyway - I'm delighted that I can now get Black only crop marks for text publications now.

Unfortunately, for forms, it's the Acrobat team, not the ID team, that has final control. For the moment, what you see is all you get.

Stix,

In addition to what Peter said, keep in mind that Adobe has no control over the PDF specification any more. It's in the hands of an ISO committee. InDesign couldn't willy nilly add stuff to PDF forms that weren't supported by the standard and would work with all the PDF readers out there.

Weeeeeellll....

in this case, I think it is more about InDesign not having the capability to export form configurations as well as Acrobat Pro is able to. And that has nothing to do with the spec.

In fairness to the InDesign team, they are limited by the knobs, tools, and access that are given to them by the Adobe PDF Library, which is a software resource maintained by the Acrobat team (I think; I'm not an expert on internal Adobe team breakdowns).

But while perhaps we can understand why the InDesign team doesn't have the tools to do a whole lot more, we can certainly blame Adobe for that. It's not related to the standards process.

Err, what? "pre populated library"? Do you mean the Adobe PDF Library? It's not like an InDesign Library. It's a library in the C++ sense. A collection of functions and classes and data structures that export an interface to another program.

When you say "code," what do you mean? Surely not the C++ code? Because there's like no chance that Adobe's going to release that. But there isn't any other stuff that could be represented by "code" here, unless I'm missing something. I suppose there's the "PDF code" which you can see on inspection by looking at the result of the PDF export.

But I think that's not what you mean? I am sorely confused.

Stix Hart wrote:

 

If you can add a specific feature to a PDF form in Acrobat why would they stop you doing that same thing in InDesign? 

I believe some of it has to do with document security, and I too am basically ignorant of internals, but I seem to remember it being metioned that ID doesn't have the security tools available in Acrobat and that limits some of the functionality that can be included.

Locking out-of-date thread now being used for spam