Desktop Publishing Software Recommendations Needed

Long way of saying that I want the process automated.




I believe iStudio indicated a year ago (about last December) that they were planning to release an application called iStudio Bookbuilder which was to include an indexing function and be more "text" oriented than their current graphic oriented iStudio Publisher application. Unfortunately, I have not seen any updates to their announcement since that time. (Not sure if they gave up on the project or are waiting until next January's anniversary of Publisher to make further announcements regarding both Bookbuilder and their Publisher Pro projects.)

Apple still saves Adobe PDF 1.3...




Don't believe anyone here would dispute anything you have said. The quoted text was merely a question/comment geared to better understand Scott's goal and, thus, possibly offer other recommendations in addition to those already made by Peter. I am interested in the "personal publishing" of digital content for reading to my grandchildren from devices such as the Kindle 2 and Sony Edition readers. As such, I am more worried about the sequential processing of layer objects then color management, the auto-generation of an interactive TOC and/or hyperlinks than placing text on a curve, the number/type of export formats an application may support than layout options, and/or the ease of use of a particular application. While I feel comfortable using Adobe InDesign CS, the CS4 version is simply not worth the effort for my purposes while Pages has most of the features I require and is easy to use, it lacks direct support for many of the file formats I would like to see included. The real problem seems to be that "self publishing" apps are still, for the most part, in their infancy as far as the home user is concerned.

So, in other words, if I want a high quality pdf, I need to use a program other than Pages?

No.

If, as we are led to believe, Adobe PDF is "paper without the chase" and Microsoft XPS is a "paper specification", then it is absurd to advertise support for ICC imaging and Unicode imaging in system software services unless said system level services are (1) technically useable and (2) user friendly.

The previous Chair of ISO 15930 PDF/X in a talk to the British Standards Institute in 2005 indisputably correctly noted that if support for authoring document descriptions that are properly repurposeable is not available to all, then problems are produced - not documents.

I reviewed Apple QuickDraw GX for the technical trade press in 1994 and went along with the argument that device independence belongs in system level services, not in application services. I also note that Apple repurposed the 1994 argument for OS X.

Henrik

I am interested in the "personal publishing" of digital content for reading to my grandchildren from devices such as the Kindle 2 and Sony Edition readers ... The real problem seems to be that "self publishing" apps are still, for the most part, in their infancy as far as the home user is concerned.

These devices do not make sense with a document description statically designed for print. These devices demand structure information and semantic information for navigation by search, and for reflowing and rendering of the layout. It's not a question of Pages, or QuarkXPress, or InDesign but of the underlying document description model.

Henrik

Thanks for the heads up Scott, next time I'll know.

I spent about 2-3 months all up in Italy but not all in one go, so my Italian is not as good as my German which is more fluent, if ungrammatic.

The funniest part of it was when trying to find the Lavenderia, I asked a Carabinero, as any English speaker would do, except his Italian was so bad being a southerner, a local had to translate my Italian to his Italian and back.

The same thing happened to me in German with a waitress in a small town outside of Basel, which speaks the equivalent of Glaswegian in English. Much worse than Alsatian (for Yvan's benefit) which at least I could understand if not pronounce.

Peter

btw I just looked up the meaning of asciugare, it is literally juicer, no wonder I wouldn't have guessed it.

Scott

If you want to know how to improve your pdf click on my blue name.

Peter

These devices do not make sense with a document description statically designed for print.




This may be so from a "print" point of view, but devices work at least as well as the Adobe Reader, Preview, and similar software readers from a scaled graphic standpoint which meet my needs at this point in time.




These devices demand structure information and semantic information for navigation by search, and for reflowing and rendering of the layout.




The required structure information is contained in the source authoring application and is implemented as needed according to the user's final export format or intermediate file format and conversion work flow(s). Thus, once again, navigation in my PDF and AZW files are compatible with the target devices mentioned above. As to reflowing, a PDF file remains problematic as far as true reflowing is concerned -- especially where the content is "reflowed" (more of a rescale operation) to a fixed display area -- which is why such content must be output to a custom document size targeted specifically for the device and things like text outlining and background layers should be avoided. (Was, however, happy to discover that shadowing is reasonably well rendered even on Sony 8-level grayscale devices.) As to "searches," that is not something I require. Am, however, anxious to see how well freehand annotation is implemented on the Touch and Daily Edition readers when applied to PDF and/or ePUB files. (Never thought I would use this capability, but now would likely find this a handy feature for noting spelling and typographical errors in my test files.)




It's not a question of Pages, or QuarkXPress, or InDesign but of the underlying document description model.




I'm not sure, but it seems to me that you are primarily focused on an absolute "print" model and how it is implemented on hardware devices and disregarding other digital options now afforded by eBook authoring, eBook publishing, and eBook distribution via a growing number of services and commercial storefronts. While your comments are valid and should be considered in recommending authoring/publishing applications as originally requested here, not all potential authors may wish to limit themselves to a traditional "print" model be it in paper or electronic in medium.




UPDATE:
Scott, just received some additional information from iStudio. Have not really tested their $49 layout application as it lacks most of the text handling capabilities I have come to expect in Pages. Have, however, downloaded the 30-day trial app to check out its use as an alternative newsletter creation program. Unfortunately, it appears it will be 12 months plus before Bookbuilder is planed for release. According to their posted "Publisher Roadmap," it would seem that many of the features expected to be incorporated into Bookbuilder (targeted to sell for $149) will be prototyped in Publisher over this time frame (e.g., ePUB and RTF export alternatives to PDF which I am interested in testing). In short, it is unlikely that either of these applications will suit your current needs in their present form.

devices work at least as well as the Adobe Reader, Preview, and similar software readers from a scaled graphic standpoint which meet my needs at this point in time.

Have you actually been successful in creating satisfactory Kindle stuff of the type you describe in pdf format? All the guides I've seen for producing content for that device are for html (which kind of rules out using Pages), e.g.

http://kindleformatting.com/formatting.php

Jon

I gave iStudio Publisher a fairly good workout, as I have most of my listed DTP alternatives.

iStudio is not ready for any serious work. It is indeed a diamond in the rough.

I do hope that it fixes all the rough edges, because potentially it could be usable and it is in the low end price range that Pages users would expect.

iCalamus is much closer to a real DTP application with the major Achilles heal that it still uses OSX's print engine. It takes a serious hike in price though, being at least 4 times as expensive as Pages, Swift Publisher and iStudio Publisher.

Peter

it seems to me that you are primarily focused on an absolute "print" model and how it is implemented on hardware devices and disregarding other digital options now afforded by eBook authoring, eBook publishing, and eBook distribution via a growing number of services and commercial storefronts.

Erhm ... Peter tends to talk in terms of device dependent 'Print, then Distribute' for PDF/X-1a where all objects must be deviceCMYK or spot and where the precise press condition is predictable before any object is placed in the page design.

As far as I remember, Thomas predicted that Apple with its system level software and application software being what it is, would be highly successful in the much discussed entry into eBook and edutainment markets where fine typography and full repurposing for Unicode imaging is important.

The last I looked, I wrote that Apple as a matter of fact does not support ISO 19005-1:2005 PDF/A. Apple only supports ISO 15930:2002 PDF/X-3 which has nothing to do with structure information, semantic information, and the remotest notion of reflowing Apple's PDF.

No crystal ball here, nor divining rod either. But let me tell you that the University of Nottingham in 1995 recorded 3000 PDF files on a web crawl. A web crawl of this university's site today would probably show many times as many PDF files.

Microsoft XPS ('Metro') is final form specification, but implementations are pending. Adobe PDFXML ('Mars' or PDF 2.0) is not final form specification, it is only version 0.7 and not yet version 1.0. Marrying content-based document markup with appearance-based document description is the likely direction of development aka a migration path for PDF to compete with XPS.

Henrik

As far as I remember, Thomas predicted that Apple with its system level software and application software being what it is, would be highly successful in the much discussed entry into eBook and edutainment markets where fine typography and full repurposing for Unicode imaging is important.

Actually what I predicted was that the things you mention above as being "important" would be irrelevant to the success of such a device. Anyone who has some experience with a Kindle, iPhone, or similar can tell you what features will make them buy an Apple tablet, and those are not among them.

Someone needs to put a large *Wrong Way Go Back* sign on this electronic book idea.

Just because the consequences are invisible, of producing a persistent energy consuming "solution" in place of a static material consuming solution, it does not make it wise.

We now have "always on" computers, photo viewers, hard drives, plasma/LCD TVs etc that do not always replace their older less energy consuming alternatives.

The Internet is now sucking an estimated massive 10% of all electricity consumption around the world.

As there is no meter on this consumption, people are ignoring it as if it didn't exist.

Peter

Have you actually been successful in creating satisfactory Kindle stuff of the type you describe in pdf format?




Yes, or at least what I consider satisfactory Kindle 2 AZW file results which retain my text formatting, chapter title formats, auto-generated TOC, graphics, etc. However, my work flow is somewhat different than you describe as follows...

1) I start off by copy/pasting a source document (e.g., a public domain Gutenberg Project HTML file) to Pages.
2) I then delete extraneous references per paragraph 1.E. of the Gutenberg license, resize/reformat the text as desired, ensure inline graphics are placed as I want them, create my interactive TOC, reinsert/reformat graphic shape sub-chapter dividers if present in the original file, and proof the document as best I can. (Always seem to find additional mistakes when reading the finished document on the device and end up correcting and re-exporting the Pages document to the final file format.)
3) In the case of AZW files, I export from Pages to an intermediate DOC file which retains the look and feel (i.e., formatting, TOC, graphics, dividers, etc. described above) of my Pages document. The DOC file is then e-mailed to my Amazon area for free conversion to AZW and free retransmission back to my computer via e-mail for posting to my Kindle 2 device. (This process in described in the Kindle 2 user manual and on the Amazon site.)
4) Finally, I transfer the finished files to my eBook reader device. In my case, I use Calibre for management of both my Amazon Kindle 2 and Sony Pocketbook Edition device files from a single application.