Skip to main content

Home/ Groups/ Document Wars
Gary Edwards

Readium at the London Book Fair 2014: Open Source for an Open Publishing Ecosystem: Rea... - 0 views

  •  
    excerpt/intro:
    Last month marked the one-year anniversary of the formation of the Readium Foundation (Readium.org), an independent nonprofit launched in March 2013 with the objective of developing commercial-grade open source publishing technology software. The overall goal of Readium.org is to accelerate adoption of ePub 3, HTML5, and the Open Web Platform by the digital publishing industry to help realize the full potential of open-standards-based interoperability. More specifically, the aim is to raise the bar for ePub 3 support across the industry so that ePub maintains its position as the standard distribution format for e-books and expands its reach to include other types of digital publications.

    In its first year, the Readium consortium added 15 organizations to its membership, including Adobe, Google, IBM, Ingram, KERIS (S. Korea Education Ministry), and the New York Public Library. The membership now boasts publishers, retailers, distributors and technology companies from around the world, including organizations based in France, Germany, Norway, U.S., Canada, China, Korea, and Japan. In addition, in February 2014 the first Readium.org board was elected by the membership and the first three projects being developed by members and other contributors are all nearing "1.0" status.

    The first project, Readium SDK, is a rendering "engine" enabling native apps to support ePub 3. Readium SDK is available on four platforms-Android, iOS, OS/X, and Windows- and the first product incorporating Readium SDK (by ACCESS Japan) was announced last October. Readium SDK is designed to be DRM-agnostic, and vendors Adobe and Sony have publicized plans to integrate their respective DRM solutions with Readium SDK.

    A second effort, Readium JS, is a pure JavaScript ePub 3 implementation, with configurations now available for cloud based deployment of ePub files, as well as Readium for Chrome, the successor to the original Readium Chrome extension developed by IDPF as the
  •  
    excerpt/intro:
    Last month marked the one-year anniversary of the formation of the Readium Foundation (Readium.org), an independent nonprofit launched in March 2013 with the objective of developing commercial-grade open source publishing technology software. The overall goal of Readium.org is to accelerate adoption of ePub 3, HTML5, and the Open Web Platform by the digital publishing industry to help realize the full potential of open-standards-based interoperability. More specifically, the aim is to raise the bar for ePub 3 support across the industry so that ePub maintains its position as the standard distribution format for e-books and expands its reach to include other types of digital publications.

    In its first year, the Readium consortium added 15 organizations to its membership, including Adobe, Google, IBM, Ingram, KERIS (S. Korea Education Ministry), and the New York Public Library. The membership now boasts publishers, retailers, distributors and technology companies from around the world, including organizations based in France, Germany, Norway, U.S., Canada, China, Korea, and Japan. In addition, in February 2014 the first Readium.org board was elected by the membership and the first three projects being developed by members and other contributors are all nearing "1.0" status.

    The first project, Readium SDK, is a rendering "engine" enabling native apps to support ePub 3. Readium SDK is available on four platforms-Android, iOS, OS/X, and Windows- and the first product incorporating Readium SDK (by ACCESS Japan) was announced last October. Readium SDK is designed to be DRM-agnostic, and vendors Adobe and Sony have publicized plans to integrate their respective DRM solutions with Readium SDK.

    A second effort, Readium JS, is a pure JavaScript ePub 3 implementation, with configurations now available for cloud based deployment of ePub files, as well as Readium for Chrome, the successor to the original Readium Chrome extension developed by IDPF as the
Gary Edwards

Dump the file server: Why we moved to the SharePoint Online cloud [review] - 0 views

  • For this article, I wanted to focus on an important aspect of our move to Office 365, and that was our adoption of SharePoint Online as our sole document file server. I know, how passé for me to call it a file server as it represents everything that fixes what plagues traditional file servers and NASes.

    Let's face it: file servers have been a necessary evil, not a nicety that have enabled collaboration and seamless access to data. They offer superior security and storage space, but this comes at the price of external access and coauthoring functionality. Corporate IT departments have had a band-aid known as VPN for some time now, but it falls short of being the panacea vendors like Cisco make it out to be.

    I know this well -- I support these kinds of VPNs day to day. Their licensing is convoluted, they're drowning in client application bug hell, and most of all, bound by the performance bottlenecks on either the client or server end.

  • I previously wrote about how my company used to juggle two distinct file storage systems. We had Google Drive as our web-based cloud document platform, buts its penetration didn't go much further than its Google Docs functionality. That's because Google has a love-hate relationship with any Office file that's not a Google Doc. Sure, you can upload it and store it on the service, but the bells and whistles end there. Want to edit it with others? It MUST be converted to Google's format.

    And so we had to keep a crutch in place for everything else that had to stay in traditional Office formats, either due to customer requirements, complex formatting, or other reasons. That other device for us was a simple QNAP NAS box with 1.5TB of space.

  • I previously wrote about how my company used to juggle two distinct file storage systems. We had Google Drive as our web-based cloud document platform, buts its penetration didn't go much further than its Google Docs functionality. That's because Google has a love-hate relationship with any Office file that's not a Google Doc. Sure, you can upload it and store it on the service, but the bells and whistles end there. Want to edit it with others? It MUST be converted to Google's format.
  • ...9 more annotations...
  • And so we had to keep a crutch in place for everything else that had to stay in traditional Office formats, either due to customer requirements, complex formatting, or other reasons. That other device for us was a simple QNAP NAS box with 1.5TB of space.
  • We liked Google Drive's real time collaboration functionality, but the way it treated non-Docs files was pretty pitiful.
  • Dropbox for Business provides the best headroom for growth, but it's starting monthly price is too much to swallow.
  • And Box and Egnyte don't bring much more to the table besides bona fide cloud storage and sync;
  • SharePoint Online offers a rich ecosystem that we can grow on.
  • For the purpose of running our day to day business needs, SharePoint Online has taken over for both Google Drive and our former NAS alike. We don't have to convert items to and from Google Docs anymore just to collaborate. We have as good, or better, permissions in SharePoint compared to Google Drive. And the search power in SharePoint is disgustingly accurate, providing the accuracy and file previews that we were used to on Google Drive.
  • SharePoint Online is first and foremost a cloud solution that has additional tie-ins with Office Online products, OneDrive, etc that may or may not exist in the on-premise version of the product.
  • It's a cloud file server (the focus of this piece). It's a content search hub. It can run public websites and internal intranets. It can help handle complex document workflows. You can even run Access databases on it.
  • I can finally work as I wish, in-browser or in Office 2013 -- or both at once. My entire company "file server" is synced via OneDrive for Business to my Thinkpad, and likewise, I can edit any files in a browser via Office Online apps. It's a nirvana that Google Drive almost afforded us, if it weren't for Google's distaste of traditional Office files. It's good to know you can have your cake and eat it too.
  •  
    Yesterday Google announced dramatic price reductions for their Cloud Computing platform. This announcement was followed immediately by a similar announcement from Amazon. But what about Microsoft?

    The truth is that Microsoft doesn't need to reduce prices, and they are forcing both Google and Amazon reductions. My guess is that there are more reductions to come too.

    The answer is in this review of SharePoint OnLine and Office 365, where the author points out the fact that Google Drive / Apps totally mangles an MSOffice document. Once Google converts the documents, they are useless.

    "I previously wrote about how my company used to juggle two distinct file storage systems. We had Google Drive as our web-based cloud document platform, buts its penetration didn't go much further than its Google Docs functionality. That's because Google has a love-hate relationship with any Office file that's not a Google Doc. Sure, you can upload it and store it on the service, but the bells and whistles end there. Want to edit it with others? It MUST be converted to Google's format.

    And so we had to keep a crutch in place for everything else that had to stay in traditional Office formats, either due to customer requirements, complex formatting, or other reasons. That other device for us was a simple QNAP NAS box with 1.5TB of space."

    In 2006-2007, when we were in the middle of the great ODF vs OOXML document wars, I had a conversation with Google's Open Source - Opoen Standards guru, Chris DiBona. It was during the Massachusetts crisis, and we were trying to garner Google Corporate support for ODF. Chris listened to my pitch and summarized his position that conversion methods were very advanced, and going forward, file formats really didn't matter. He famously said, "Let a thousand formats bloom".

    I wonder if he still thinks that?
Gary Edwards

ODF vs. OOXML: War of the Words | Andrew Updegrove: Tales of Adversego - 0 views

  •  
    "For some time I've been considering writing a book about what has become a standards war of truly epic proportions.  I refer, of course, to the ongoing, ever expanding, still escalating conflict between ODF and OOXML, a battle that is playing out across five continents and in both the halls of government and the marketplace alike.  And, needless to say, at countless blogs and news sites all the Web over as well.

    Arrayed on one side or the other, either in the forefront of battle or behind the scenes, are most of the major IT vendors of our time.  And at the center of the conflict is Microsoft, the most successful software vendor of all time, faced with the first significant challenge ever to one of its core businesses and profit centers - its flagship Office productivity suite.

    The story has other notable features as well:  ODF is the first IT standard to be taken up as a popular cause, and also represents the first "cross over" standards issue that has attracted the broad support of the open source community.  Then there are the societal dimensions: open formats are needed to safeguard our culture and our history from oblivion.  And when implemented in open source software and deployed on Linux-based systems (not to mention One Laptop Per Child computers), the benefits and opportunities of IT become more available to those throughout the third world.

    There is little question, I think, that regardless of where and how this saga ends, it will be studied in business schools and by economists for decades to come.  What they will conclude will depend in part upon the materials we leave behind for them to examine.  That's one of the reasons I'm launching this effort now, as a publicly posted eBook in progress, rather than waiting until some indefinite point in the future when the memories of the players in this drama have become colored by the passage of time and the influence of later events.

    My hope is that those of you who have played or are n
Gary Edwards

XML Production Workflows? Start with the Web and XHTML - 0 views

  • Challenges: Some Ugly Truths

    The challenges of building—and living with—an XML workflow are clear enough. The return on investment is a long-term proposition.

    Regardless of the benefits XML may provide, the starting reality is that it represents a very different way of doing things than the one we are familiar with. The Word Processing and Desktop Publishing paradigm, based on the promise of onscreen, WYSIWYG layout, is so dominant as to be practically inescapable. It has proven really hard to get from here to there, no matter how attractive XML might be on paper.

    A considerable amount of organizational effort and labour must be expended up front in order to realize the benefits. This is why XML is often referred to as an “investment”: you sink a bunch of time and money up front, and realize the benefits—greater flexibility, multiple output options, searching and indexing, and general futureproofing—later, over the long haul. It is not a short-term return proposition.

    And, of course, the returns you are able to realize from your XML investment are commensurate with what you put in up front: fine-grained, semantically rich tagging is going to give you more potential for searchability and recombination than a looser, more general-purpose approach, but it sure costs more. For instance, the Text Encoding Initiative (TEI) is the grand example of pouring enormous amounts of energy into the up-front tagging, with a very open-ended set of possibilities down the line. TEI helpfully defines a level to which most of us do not have to aspire.[5]

    But understanding this on a theoretical level is only part of the challenge. There are many practical issues that must be addressed. Software and labour are two of the most critical. How do you get the content into XML in the first place? Unfortunately, despite two decades of people doing SGML and XML, this remains an ugly question.

  • Practical Challenges

    In 2009, there is still no truly likeable—let alone standard—editing and authoring software for XML. For many (myself included), the high-water mark here was Adobe’s FrameMaker, substantially developed by the late 1990s. With no substantial market for it, it is relegated today mostly to the tech writing industry, unavailable for the Mac, and just far enough afield from the kinds of tools we use today that its adoption represents a significant hurdle. And FrameMaker was the best of the breed; most of the other software in decent circulation are programmers’ tools—the sort of things that, as Michael Tamblyn pointed out, encourage editors to drink at their desks.

    The labour question represents a stumbling block as well. The skill-sets and mind-sets that effective XML editors need have limited overlap with those needed by literary and more traditional production editors. The need to think of documents as machine-readable databases is not something that comes naturally to folks steeped in literary culture. In combination with the sheer time and effort that rich tagging requires, many publishers simply outsource the tagging to India, drawing a division of labour that spans oceans, to put it mildly.

    Once you have XML content, then what do you do with it? How do you produce books from it? Presumably, you need to be able to produce print output as well as digital formats. But while the latter are new enough to be generally XML-friendly (e-book formats being largely XML based, for instance), there aren’t any straightforward, standard ways of moving XML content into the kind of print production environments we are used to seeing. This isn’t to say that there aren’t ways of getting print—even very high-quality print—output from XML, just that most of them involve replacing your prepress staff with Java programmers.

  • Why does this have to be so hard?

    It’s not that XML is new, or immature, or untested. Remember that the basics have been around, and in production, since the early 1980s at least. But we have to take account of a substantial and long-running cultural disconnect between traditional editorial and production processes (the ones most of us know intimately) and the ways computing people have approached things.

    Interestingly, this cultural divide looked rather different in the 1970s, when publishers were looking at how to move to digital typesetting. Back then, printers and software developers could speak the same language. But that was before the ascendancy of the Desktop Publishing paradigm, which computerized the publishing industry while at the same time isolating it culturally. Those of us who learned how to do things the Quark way or the Adobe way had little in common with people who programmed databases or document-management systems. Desktop publishing technology isolated us in a smooth, self-contained universe of toolbars, grid lines, and laser proofs.

    So, now that the reasons to get with this program, XML, loom large, how can we bridge this long-standing divide?

  • ...44 more annotations...
  • Using the Web as a Production Platform

    The answer, I think, is right in front of you. The bridge is the Web, a technology and platform that is fundamentally based on XML, and which many publishers are by now comfortably familiar with. Perhaps not entirely comfortably, but at least most publishers are already working with the Web; they already either know or have on staff people who understand it and can work with it.

    The foundation of our argument is this: rather than looking at jumping to XML in its full, industrial complexity, which seems to be what the O'Reilly-backed StartWithXML initiative[6] is suggesting, publishers instead leverage existing tools and technologies—starting with the Web—as a means of getting XML workflows in place. This means making small investments and working with known tools rather than spending tens of thousands of dollars on XML software and rarefied consultants. It means re-thinking how the existing pieces of the production toolchain fit together; re-thinking the existing roles of software components already in use. It means, fundamentally, taking the Web seriously as a content platform, rather than thinking of it as something you need to get content out to, somehow. If nothing else, the Web represents an opportunity to think about editorial and production from outside the shrink-wrapped Desktop Publishing paradigm.

  • Is the Web made of Real XML?

    At this point some predictable objections can be heard: wait a moment, the Web isn’t really made out of XML; the HTML that makes up most of the Web is at best the bastard child of SGML, and it is far too flaky/unstructured/underpowered to be taken seriously.

    We counter by arguing that although HTML on the Web exists in a staggering array of different incarnations, and that the majority of it is indeed an unstructured mess, this does not undermine the general principle that basic, ubiquitous Web technologies can make a solid platform for content management, editorial process, and production workflow.

  • With the advent of a published XML standard in the late 1990s came the W3C’s adoption of XHTML: the realization of the Web’s native content markup as a proper XML document type. Today, its acceptance is almost ubiquitous, even while the majority of actual content out there may not be strictly conforming. The more important point is that most contemporary Web software, from browsers to authoring tools to content management systems (from blogs to enterprise systems), are capable of working with clean, valid XHTML. Or, to put the argument the other way around, clean, valid XHTML content plays absolutely seamlessly with everything else on the Web.[7]
  • The objection which follows, then, will be that even if we grant that XHTML is a real XML document type, that it is underpowered for “serious” content because it is almost entirely presentation (formatting) oriented; it lacks any semantic depth. In XHTML, a paragraph is a paragraph is a paragraph, as opposed to a section or an epigraph or a summary.
  • n contrast, more “serious” XML document types like DocBook[8] or DITA-derived schemas[9] are capable of making semantic distinctions about content chunks at a fine level of granularity and with a high degree of specificity.
  • So there is an argument for recalling the 80:20 rule here. If XHTML can provide 80% of the value with just 20% of the investment, then what exactly is the business case for spending the other 80% to achieve that last 20% of value? We suspect the ratio is actually quite a bit steeper than 80:20 for most publishers.
  • IDML is a well thought-out XML standard that achieves two very different goals simultaneously: it preserves all of the information that InDesign needs to do what it does; and it is broken up in a way that makes it possible for mere mortals (or at least our Master of Publishing students) to work with it.
  • XHTML, on the other hand, is supported by a vast array of quotidian software, starting with the ubiquitous Web browser. For this very reason, XHTML is in fact employed as a component part of several more specialized document types (ONIX and ePub among them).
  • Why re-invent a general-purpose prose representation when XHTML already does the job?
  • It is worth pausing for a moment to consider the role of XHTML in the ePub standard for ebook content. An ePub file is, anatomically, a simply disguised zip archive. Inside the zip archive are a few standard component parts: there are specialized files that declare metadata about the book, and about the format of the book. And then there is the book’s content, represented in XHTML. An ePub book is a Web page in a wrapper.
  • To sum up the general argument: the Web as it already exists presents incredible value to publishers, as a platform for doing XML content management with existing (and often free) tools, and without having to go blindly into the unknown. At this point, we can offer a few design guidelines:

    • prefer existing and/or ubiquitous tools over specialized ones wherever possible;
    • prefer free software over proprietary systems where possible;
    • prefer simple tools controlled and coordinated by human beings over fully automated (and therefore complex) systems;
    • play to our strengths: use Web software for storing and managing content, use layout software for layout, and keep editors and production people in charge of their own domains.
  • Putting the Pieces Together: A Prototype
  • At the SFU Master of Publishing Program, we have been chipping away at this general line of thinking for a few years. Over that time, Web content management systems have been getting more and more sophisticated, all the while getting more streamlined and easier to use. (NB: if you have a blog, you have a Web content management system.) The Web is beginning to be recognized as a writing and editing environment used by millions of people. And the ways in which content is represented, stored, and exchanged online have become increasingly robust and standardized.
  • The missing piece of the puzzle has been print production: how can we move content from its malleable, fluid form on line into the kind of high-quality print production environments we’ve come to expect after two decades of Desktop Publishing?
  • Anyone who has tried to print Web content knows that the existing methods leave much to be desired (hyphenation and justification, for starters). In the absence of decent tools for this, most publishers quite naturally think of producing the print content first, and then think about how to get material onto the Web for various purposes. So we tend to export from Word, or from Adobe, as something of an afterthought.
  • While this sort of works, it isn’t elegant, and it completely ignores the considerable advantages of Web-based content management.
  • Content managed online is stored in one central location, accessible simultaneously to everyone in your firm, available anywhere you have an Internet connection, and usually exists in a much more fluid format than Word files. If only we could manage the editorial flow online, and then go to print formats at the end, instead of the other way around. At SFU, we made several attempts to make this work by way of the supposed “XML import” capabilities of various Desktop Publishing tools, without much success.[12]
  • In the winter of 2009, Adobe solved this part of the problem for us with the introduction of its Creative Suite 4. What CS4 offers is the option of a complete XML representation of an InDesign document: what Adobe calls IDML (InDesign Markup Language).
  • The IDML file format is—like ePub—a simply disguised zip archive that, when unpacked, reveals a cluster of XML files that represent all the different facets of an InDesign document: layout spreads, master pages, defined styles, colours, and of course, the content.
  • What this represented to us in concrete terms was the ability to take Web-based content and move it into InDesign in a straightforward way, thus bridging Web and print production environments using existing tools and skillsets, with a little added help from free software.
  • Such a workflow—beginning with the Web and exporting to print—is surely more in line with the way we will do business in the 21st century, where the Web is the default platform for reaching audiences, developing content, and putting the pieces together. It is time, we suggest, for publishers to re-orient their operations and start with the Web.
  • We would take clean XHTML content, transform it to IDML-marked content, and merge that with nicely designed templates in InDesign.
  • The result is an almost push-button publication workflow, which results in a nice, familiar InDesign document that fits straight into the way publishers actually do production.
  • Tracing the steps

    To begin with, we worked backwards, moving the book content back to clean XHTML.

  • The simplest method for this conversion—and if you want to create Web content, this is an excellent route—was to use Adobe’s “Export to Digital Editions” option, which creates an ePub file.
  • Recall that ePub is just XHTML in a wrapper, so within the ePub file was a relatively clean XHTML document. It was somewhat cleaner (that is, the XHTML tagging was simpler and less cluttered) than InDesign’s other Web-oriented exports, possibly because Digital Editions is a well understood target, compared with somebody’s website.
  • In order to achieve our target of clean XHTML, we needed to do some editing; the XHTML produced by InDesign’s “Digital Editions” export was presentation-oriented. For instance, bulleted list items were tagged as paragraphs, with a class attribute identifying them as list items. Using the search-and-replace function, we converted such structures to proper XHTML list and list-item elements. Our guiding principle was to make the XHTML as straightforward as possible, not dependent on any particular software to interpret it.
  • We broke the book’s content into individual chapter files; each chapter could then carry its own basic metadata, and the pages conveniently fit our Web content management system (which is actually just a wiki). We assembled a dynamically generated table of contents for the 12 chapters, and created a cover page. Essentially, the book was entirely Web-based at this point.
  • When the book chapters are viewed online, they are formatted via a CSS2 stylesheet that defines a main column for content as well as dedicating screen real estate for navigational elements. We then created a second template to render the content for exporting; this was essentially a bare-bones version of the book with no navigation and minimal styling. Pages (or even the entire book) can be exported (via the “Save As...” function in a Web browser) for use in either print production or ebook conversion. At this point, we required no skills beyond those of any decent Web designer.
  • Integrating with CS4 for Print

    Adobe’s IDML language defines elements specific to InDesign; there is nothing in the language that looks remotely like XHTML. So a mechanical transformation step is needed to convert the XHTML content into something InDesign can use. This is not as hard as it might seem.

  • Both XHTML and IDML are composed of straightforward, well-documented structures, and so transformation from one to the other is, as they say, “trivial.” We chose to use XSLT (Extensible Stylesheet Language Transforms) to do the work. XSLT is part of the overall XML specification, and thus is very well supported in a wide variety of tools. Our prototype used a scripting engine called xsltproc, a nearly ubiquitous piece of software that we found already installed as part of Mac OS X (contemporary Linux distributions also have this as a standard tool), though any XSLT processor would work.
  • In other words, we don’t need to buy InCopy, because we just replaced it with the Web. Our wiki is now plugged directly into our InDesign layout. It even automatically updates the InDesign document when the content changes. Credit is due at this point to Adobe: this integration is possible because of the open file format in the Creative Suite 4.
  • We wrote an XSLT transformation script[18] that converted the XHTML content from the Web into an InCopy ICML file. The script itself is less than 500 lines long, and was written and debugged over a period of about a week by amateurs (again, the people named at the start of this article). The script runs in a couple of seconds, and the resulting .icml file can then be “placed” directly into an InDesign template. The ICML file references an InDesign stylesheet, so the template file can be set up with a house-styled layout, master pages, and stylesheet definitions for paragraphs and character ranges.
  • The result is very simple and easy to use. Our demonstration requires that a production editor run the XSLT transformation script manually, but there is no reason why this couldn’t be built directly into the Web content management system so that exporting the content to print ran the transformation automatically. The resulting file would then be “placed” in InDesign and proofed.
  • It should be noted that the Book Publishing 1 proof-of-concept was artificially complex; we began with a book laid out in InDesign and ended up with a look-alike book laid out in InDesign. But next time—for instance, when we publish Book Publishing 2—we can begin the process with the content on the Web, and keep it there throughout the editorial process. The book’s content could potentially be written and edited entirely online, as Web content, and then automatically poured into an InDesign template at proof time. “Just in time,” as they say.

    This represents an entirely new way of thinking of book production. With a Web-first orientation, it makes little sense to think of the book as “in print” or “out of print”—the book is simply available, in the first place online; in the second place in derivative digital formats; and third, but really not much more difficult, in print-ready format, via the usual InDesign CS print production system publishers are already familiar with.

  • Creating Ebook Files

    Creating electronic versions from XHTML source is vastly simpler than trying to generate these out of the existing print process. The ePub version is extremely easy to generate; so is online marketing copy or excerpts for the Web, since the content begins life Web-native.

  • Since an ePub file is essentially XHTML content in a special wrapper, all that is required is that we properly “wrap” our XHTML content. Ideally, the content in an ePub file is broken into chapters (as ours was) and a table of contents file is generated in order to allow easy navigation within an ebook reader. We used Julian Smart’s free tool eCub[19] to simply and automatically generate the ePub wrapper and the table of contents. The only custom development we did was to create a CSS stylesheet for the ebook so that headings and paragraph indents looked the way we wanted. Starting with XHTML content, creating ePub is almost too easy.
  • today, we are able to put the process together using nothing but standard, relatively ubiquitous Web tools: the Web itself as an editing and content management environment, standard Web scripting tools for the conversion process, and the well-documented IDML file format to integrate the layout tool.
  • Our project demonstrates that Web technologies are indeed good enough to use in an XML-oriented workflow; more specialized and expensive options are not necessarily required. For massive-scale enterprise publishing, this approach may not offer enough flexibility, and the challenge of adding and extracting extra semantic richness may prove more trouble than it's worth.
  • But for smaller firms who are looking at the straightforward benefits of XML-based processes—single source publishing, online content and workflow management, open and accessible archive formats, greater online discoverability—here is a way forward.
  • Rather than a public-facing website, our system relies on the Web as a content management platform—of course a public face could easily be added.
  • The final piece of our puzzle, the ability to integrate print production, was made possible by Adobe's release of InDesign with an open XML file format. Since the Web's XHTML is also XML, is can be easily and confidently transformed to the InDesign format.
  • Furthermore, just to get technical for a moment, XHTML is extensible in a fairly straightforward way, through the common “class” attribute on each element. Web developers have long leveraged this kind of extensibility in the elaboration of “microformats” for semantic-web applications.[10] There is no reason why publishers shouldn’t think to use XHTML’s simple extensibility in a similar way for their own ends.
  • Using the Web as a Production Platform
  •  
    I was looking for an answer to a problem Marbux had presented, and found this interesting article.  The issue was that of the upcoming conversion of the Note Case Pro (NCP) layout engine to the WebKit layout engine, and what to do about the NCP document format.

    My initial reaction was to encode the legacy NCP document format in XML, and run an XSLT to a universal pivot format like TEI-XML.  From there, the TEI-XML community would provide all the XSLT transformation routines for conversion to ODF, OOXML, XHTML, ePUB and HTML/CSS.

    Researching the problems one might encounter with this approach, I found this article.  Fascinating stuff.

    My take away is that TEI-XML would not be as effective a "universal pivot point" as XHTML.  Or perhaps, if NCP really wants to get aggressive; IDML - InDesign Markup Language. The important point though is that XHTML is a browser specific version of XML, and compatible with the Web Kit layout engine Miro wants to move NCP to.

    The concept of encoding an existing application-specific format in XML has been around since 1998, when XML was first introduced as a W3C standard, a "structured" subset of SGML. (HTML is also a subset of SGML).

    The multiplatform StarOffice productivity suite became "OpenOffice" when Sun purchased the company in 1998, and open sourced the code base. The OpenOffice developer team came out with a XML encoding of their existing document formats in 2000. The application specific encoding became an OASIS document format standard proposal in 2002 - also known as ODF.

    Microsoft followed OpenOffice with a XML encoding of their application-specific binary document formats, known as OOXML.

    Encoding the existing NCP format in XML, specifically targeting XHTML as a "universal pivot point", would put the NCP Outliner in the Web editor category, without breaking backwards compatibility. The trick is in the XSLT conversion process. But I think that is something much easier to handle then trying to
  •  
    I was looking for an answer to a problem Marbux had presented, and found this interesting article.  The issue was that of the upcoming conversion of the Note Case Pro (NCP) layout engine to the WebKit layout engine, and what to do about the NCP document format.

    My initial reaction was to encode the legacy NCP document format in XML, and run an XSLT to a universal pivot format like TEI-XML.  From there, the TEI-XML community would provide all the XSLT transformation routines for conversion to ODF, OOXML, XHTML, ePUB and HTML/CSS.

    Researching the problems one might encounter with this approach, I found this article.  Fascinating stuff.

    My take away is that TEI-XML would not be as effective a "universal pivot point" as XHTML.  Or perhaps, if NCP really wants to get aggressive; IDML - InDesign Markup Language.

    As an after thought, i was thinking that an alternative title to this article might have been, "Working with Web as the Center of Everything".
  •  
    I was looking for an answer to a problem Marbux had presented, and found this interesting article.  The issue was that of the upcoming conversion of the Note Case Pro (NCP) layout engine to the WebKit layout engine, and what to do about the NCP document format.

    My initial reaction was to encode the legacy NCP document format in XML, and run an XSLT to a universal pivot format like TEI-XML.  From there, the TEI-XML community would provide all the XSLT transformation routines for conversion to ODF, OOXML, XHTML, ePUB and HTML/CSS.

    Researching the problems one might encounter with this approach, I found this article.  Fascinating stuff.

    My take away is that TEI-XML would not be as effective a "universal pivot point" as XHTML.  Or perhaps, if NCP really wants to get aggressive; IDML - InDesign Markup Language. The important point though is that XHTML is a browser specific version of XML, and compatible with the Web Kit layout engine Miro wants to move NCP to.

    The concept of encoding an existing application-specific format in XML has been around since 1998, when XML was first introduced as a W3C standard, a "structured" subset of SGML. (HTML is also a subset of SGML).

    The multiplatform StarOffice productivity suite became "OpenOffice" when Sun purchased the company in 1998, and open sourced the code base. The OpenOffice developer team came out with a XML encoding of their existing document formats in 2000. The application specific encoding became an OASIS document format standard proposal in 2002 - also known as ODF.

    Microsoft followed OpenOffice with a XML encoding of their application-specific binary document formats, known as OOXML.

    Encoding the existing NCP format in XML, specifically targeting XHTML as a "universal pivot point", would put the NCP Outliner in the Web editor category, without breaking backwards compatibility. The trick is in the XSLT conversion process. But I think that is something much easier to handle then trying to
Gary Edwards

The Most Important Predictor of Sales Success - Philip Delves Broughton - Harvard Busin... - 0 views

  •  
    Good discussion on the HBR Blog Network.  I think it will be of value to your master mind group.  








    excerpt: .......................
    When you get into a bar fight, you revert to what comes naturally - the old-fashioned tactics." Your authentic self will always, eventually, come out.
    Ashok Vemuri, the head of Americas at Infosys, the Indian business process outsourcing company, made a similar point. The more salespeople he has hired, he said, the less impressed he is with the stereotypes and training which dominate the sales industry. The rigid methods taught in most sales courses, he told me, are hopeless in the field. "It seems everyone has to be either Dirty Harry, or the girl on the beach in her bikini teasing people." Instead, what he looks for are intelligence, curiosity and an agile mind. The chest-beating Alpha male of sales myth has no place in this universe. Rather, it is the low-ego character who regards client service as the highest goal who thrives. He is looking for people who can make others comfortable, who are are articulate, and who are able to deal with the unexpected..........








    "I've had salespeople with terrible accents, who don't adhere to an acceptable Westernized dress code, and misspeak words, but they are terrific story-tellers," he told me. "They relate their story to your problem and can combine experiences across functions and geographies. They cannot hold a great conversation with the CEO about wine, but they can talk specifically about technology."




    Everywhere I went, from Silicon Valley to the world of Japanese life insurance saleswomen, I heard the same story.




    I found that what most companies and sales training programs think really matters in sales is wrong. When training salespeople, they tend to propose one of two things: A sales process with methods and tricks which can move you from prospecting to closing, or a set of behaviors and character traits supposedly typical of great salespeople and worth mimicki
Gary Edwards

How Microsoft Fought True Open Standards II - Open Enterprise - 2 views

  •  
    Need to respond to Graeme Harrison's comment!!!!!!!!!!!!!!!!!!!
Paul Merrell

EUROPA - Press Releases - Antitrust: Commission opens proceedings against MathWorks - 1 views

  • Brussels, 1 March 2012 - The European Commission has opened a formal investigation to assess whether The MathWorks Inc., a U.S.-based software company, has distorted competition in the market for the design of commercial control systems by preventing competitors from achieving interoperability with its products. The Commission will investigate whether by allegedly refusing to provide a competitor with end-user licences and interoperability information, the company has breached EU antitrust rules that prohibit the abuse of a dominant position. The opening of proceedings means that the Commission will examine the case as a matter of priority. It does not prejudge the outcome of the investigation.

    The investigation follows a complaint alleging that MathWorks had refused to provide a competitor with end-user software licences and accompanying interoperability information for its flagship products "Simulink" and "MATLAB", thereby preventing it from lawfully reverse-engineering in order to achieve interoperability with these two products.

  • As in the Microsoft case (see IP/04/382 and MEMO/04/70 and MEMO/07/359), the issue of software interoperability is central to this investigation. The Commission's investigation will focus on whether MathWorks' behaviour has prevented competitors from achieving interoperability with its widely used products and thereby hindered competition in breach of Article 102 TFEU. In this context, it is recalled that the European Directive 2009/24/EC on the legal protection of computer programmes also aims to foster interoperability by allowing for reverse-engineering for interoperability purposes provided that the software at issue was lawfully acquired.
  • Background

    MathWorks' "Simulink" and "MATLAB" software products are widely used for designing and simulating control systems. Control systems are deployed in many innovative industries such as in cruise control or anti-lock braking systems (ABS) for cars.

    Article 102 TFEU prohibits the abuse of a dominant position which may affect trade and prevent or restrict competition. The implementation of this provision is defined in the Antitrust Regulation (Council Regulation No 1/2003) which can be applied by the Commission and by the national competition authorities of EU Member States.

    The Commission has informed MathWorks and the Member States' competition authorities that it has formally opened proceedings in this case.

  •  
    Commission v. MIcrosoft Redux.
Gary Edwards

PlugFest OpenDoct Society: Program and Presentations [plugtest.opendocsociety.org] - 0 views

  •  
    Presentation Schedule for OpenDocuemnt PlugFest in Berlin, Germany.
Gary Edwards

UseOffice. Net - A Modern Component to Accurately Convert Popular Office Formats - 1 views

  •  
    Cloud based Productivity Platforms and Document Management Systems just got a huge "integration with legacy desktop productivity environments"  boot from UseOffice. Net - a powerful component for integration of converting functions to Web-server ASP.NET and desktop applications Windows Forms applications for the platform of Windows, including the following versions: 2000, XP, Vista, 2008 Server, Seven.

    Applications built on the basis of this component, allow the user to quickly, and most importantly - accurately convert the formats DOC, DOCX, RTF, PPT, PDF, HTML, XHTML various documents - reports, forms, invoices, articles, forms, presentations, web pages etc.

    The converted documents are fully preserve the visual characteristics of the original, including elements of the structure and format, such as tables, font styles, colors, page margins, etc.

    UseOffice. Net Supports the following areas of transformation:

    - DOC to: html, xml, rtf, txt, pdf, docx
    - DOCX to: html, xml, rtf, txt, pdf, doc
    - HTML to: doc, rtf, txt, pdf
    - XLS to: html, xml, txt, csv, rtf, pdf
    - RTF to: html, xml, txt, doc, pdf
    - PPT to: html, xml, rtf, pdf, jpg, bmp, gif
    - XLSX to: html, xml, txt, csv, rtf, pdf

    Integrate the components into an application quickly and easily - just add a couple lines of code.

    The component is written in C # and requires the set. NET Framework and Microsoft Office (any version from 2000, XP, 2003, 2007, 2010). The following development environments: C #, VB.Net, J #, C + +. NET, Delphi.NET, ColdFusion 8, ASP.NET, and many others ...

    Combining ease of use and quality conversion UseOffice. Net allows you to set page numbers in the final document, orientation and page size settings for images and more necessary in the conversion.
Gary Edwards

The big winner from Apache OpenOffice.org | ITworld - Brian Proffitt - 1 views

  •  
    Brian is once again writing about OpenOffice and ODF, this time in the aftermath of Oracle's decision to cut OOo loose and turn it over to Apache instead of The Document Foundation.  Good discussion - features a lengthy comment from the mighty Marbux where he vigorusly corrects the river of spin coming out of IBM.  Worth a careful read!


    excerpt: IBM seems to maneuver itself to any open source project that suits its needs, and for whatever reason they have decided to hitch their wagon to Oracle's star (or vice versa). With this historical context, there is really little surprise in Oracle's decision to go with the Apache Software Foundation, because IBM was probably influencing the decision.

    My second question doesn't have a definitive answer--yet. But it needs to be answered.

    It is simply this: how will OpenOffice.org remain relevant to end users?
  •  
    I should have added to that comment a stronger warning for the Apache Foundation Board and developers considering joining the IBM-backed Apache OpenOffice.org incubator project in regard to the danger posed by IBM and Oracle's control of the OpenDocument Formats Technical Committee at OASIS, aptly characterized by IBM's Rob Weir:

    "Those who control the exchange format, can control interoperability and turn it on or off like a water faucet to meet their business objectives."

    Rob Weir, Those Who Forget Santayana, An Antic Disposition (20 December 2007), http://www.robweir.com/blog/2007/12/those-who-forget-santayana.html

    What IBM, Oracle, and others can do by manipulating the ODF specification that Apache OOo depends upon is something entirely outside the control of the Apache Foundation. And as history has taught us so well, IBM and Sun exercised that control mercilessly via their co-chairmanship of the ODF TC to block all real interoperability initiatives. That is the very reason that only ODF implementations that share the same code base can interoperate.

    And if one were tempted to think that IBM and Sun/Oracle would not even consider manipulating the ODF specification to their own commercial advantage, consider the fact that in writing the quoted statement above, Rob Weir was speaking from deep personal experience in in such activities. So beware, both Apache Foundation and LibreOffice developers.
Gary Edwards

WebODF - 1 views

shared by Gary Edwards on 01 Jun 11 - No Cached
  •  
    WebODF is a JavaScript library that makes it easy to add Open Document Format (ODF) support to your website and to your mobile or desktop application. It uses HTML and CSS to display ODF documents.

    WebODF is a Free Software project. All code is available under the AGPL. This means that you can use the code free of charge, investigate how it works, and share it with others.

    Description of WebODF From LWN:
    ODF on the web
    An especially interesting project that was presented is WebODF, which wants to bring ODF to the web. Jos van den Oever started from the observation that a lot of office suites are moving into the "cloud". Examples are Microsoft Live Office, Google Docs, and Zoho. But where are the free software alternatives for the cloud? For OpenOffice.org, KOffice, AbiWord, and Gnumeric, there are none that have a cloud version with ODF support. That was the motivation for Jos to start a project to fill in this gap and let users view and edit ODF documents on the web without losing control of the document into some company's servers.
    The strategy Jos followed was to use just HTML and JavaScript for the web application. The application then loads the XML stream of the ODF document as is into the HTML document and puts it into the DOM tree. Styling is done by applying CSS rules that are directly derived from the and elements in the ODF document. That is how WebODF was born; it is a project with the initial goal of creating a simple ODF viewer and editor for offline and online use, implemented in HTML5.
    The small code base consists of one HTML5 file and eight JavaScript files, each of which is a few hundred lines of code. The most interesting part is that it doesn't need server-side code execution: the JavaScript code is executed in the user's browser and saving the document to the web server is done using WebDAV. It supports both the Gecko and WebKit HTML engines. There is also an implementation on top of QtWebKit, which is
Gary Edwards

Florian - libopc libreoffice - 0 views

  •  
    Florian is back with another YouTube video.  This time demonstrating the wonders of ODF, using his LibOPC library to pump ODF into MSWord.  He demonstrates using the LibOPC library to make direct changes to the ODF document that are perfectly reflected in LibreOffice and MSWord, with some noted exceptions.  all of which are carefully explained and visually demonstrated.  Once again, a nice job by Florian.
Gary Edwards

Florian's libopc webkit demo - 1 views

  •  
    Florian Reuter has published another video demonstrating his LibOPC work; this time with his LibOPC library running in WebKit.
Gary Edwards

HyperOffice - Collaboration Software: Online Task, Document Management, Cloud Email , M... - 0 views

  •  
    Web - Browser based desktop productivity suite.  
Gary Edwards

Jive Buys Microsoft Office Collaboration Plugin OffiSync For Up To $30 Million - 0 views

  •  
    excerpt: OffiSync offers a a plugin for Microsoft Office that serves as a bridge between Office and Google Docs. When it first launched, the app's primary feature was to save Office documents to your Google account. It's since integrated Google Image Serach into Office, and added support for Google Sites.

    The application allows you to do Office-to-Office collaboration, and you can also have users editing the same document from Google Docs' online interface. Changes aren't synced as you type in each character, but rather each time you hit the 'save' button. Offisync is offered under a freemium model, but recently tweaked its pricing to offer more free features.

    Jive's CEO Tony Zingale says that this is a game changing acquisition for Jive, which combines computing with social collaboration to offer fully-featured social networks for businesses. Its suite of applications help businesses collaborate on a variety of tasks, including holding discussions, communication, sharing documents, blogging, running polls, and social networking features and more.

    "With OffiSync, Jive has the opportunity to become the most widely adopted Social Business platform for over 600 million Microsoft users, giving them the ability to bring social to the way they work.
Gary Edwards

A New Patent Application from Apple Introduces us to a Breakthrough Platform Independen... - 0 views

  •  
    excerpt:  This could be Apple's new internet strategy that thrusts more of us into the next phase of what is now known as the Post-PC era. In my view, this breakthrough could be a game changer.

     
    The Problem to Solve

    The recent proliferation of web browsers and computer networks has made it easy to display the same document on different computing platforms. However, inconsistencies in the way fonts are rendered across different computing platforms could cause the same document to be rendered differently for users of different computing platforms. More specifically, for a given font, the way in which metrics for various font features are interpreted, such as character height, width, leading and white space, can differ between computing platforms. These differences in interpretation could cause individual characters in a document to be rendered at different locations, which could ultimately cause the words in a document to be positioned differently between lines and pages on different computing platforms.

     

    This inconsistent rendering could be a problem for people who are collaborating on a document. For example, if one collaborator points out an error on a specific line of a specific page, another collaborator viewing the same document on a different computing platform may have to first locate the error on a different line of a different page.

    Hence, what is needed is a technique for providing consistent rendering for documents across different computer systems and computing platforms.

    Apple's patent application describe a system that typesets and renders a document in a platform-independent manner. During operation, the system first obtains the document, wherein the document includes text content and associated style information including one or more fonts. The system also generates platform-independent font metrics for the one or more fonts, wherein the platform-independent font metrics include information that could be used to determine the positions of i
Gary Edwards

Roambi Flow turns your business information into gorgeous iPad reports | VentureBeat - 0 views

  •  
    Now that's what i'm talking about!  Business documents published in an advanced Web Productivity RIA format.  Roambi Flow targets the iPAD with business reports based on SalesForce.com and other business productivity platforms hosting basic business intelligence and information.  Roambi packages the reports in the increasingly popular visually immersive webzine style similar to FlipBoard, Zite, TreeSaver, OnSwipe, Push Pop, Instapaper, Readability, Pulse, PressJack, TweetMag, Sports Illustrated and the NYTimes iOS editions.  Beautifully done.  

    My guess is that the underlying format is the visually rich and interactive HTML+ (HTML5-CSS3-JSON-JavaScript-Canvas/SVG).

    excerpt:  After revolutionizing the way companies can interact with their business data on the go with its Roambi app, San Diego-based startup Mellmo is now aiming to let you use that data to create gorgeous interactive reports and presentations with its new iPad app and publishing platform Roambi Flow.

    The move is the next step in Mellmo's plan to make business intelligence (BI) more accessible, and dare I say it, sexy.

    Mellmo's initial Roambi app integrates with existing BI systems, including Salesforce and SAP, letting business owners and executives easily make sense of their data with interactive charts, graphs and more. Now with Roambi Flow, that data can be used to create magazine-quality reports and presentations that can be shared more easily with any iPad user.

Gary Edwards

Study Shows Office Alternatives Failing to Sway Microsoft Users -- Microsoft Certified ... - 0 views

  •  
    Interesting report from Forrester on Desktop Productivity.  It seems everyone is asking about alternatives to MSOffice, but coming away empty handed.  Sounds like everyone would like to drop MSOffice, but find the alternatives wanting.  IMHO, the Web based alternatives are long on collaboration but short on productivity.  

    Compound Documents, Reports and Forms are the fuel that powers legacy workgroup productivity environments.  Web Productivity platforms have a long way to go before they can provide effective, worker facing authoring systems capable of replacing binding and messaging internals such as OLE, ODBC, MAPI, ActiveX, COM and DCOM.  

    There also seems to be considerable confusion about the difference between Web based authoring alternatives to MSOffice, and Web based Productivity Platforms.  MSOffice is the authoring system for desktop/WorkGroup productivity environments.  But having this authoring system wouldn't mean much if not for the workgroup connectivity and exchange platform behind it that makes highly productive digital business processes and systems possible.

    Linked Data, messaging, collaboration, and connectivity API's and HTML+ (HTML5, CSS3, JSON, Canvas/SVG, JavaScript) are  showing up everywhere.  But they are not exclusive to Web based authoring systems.  Any desktop authoring system should be able to take advantage of the emerging productivity platform.  

    So what's the problem with OpenOffice, Symphony, Zoho and gDocs?  OOo and Symphony can't speak language of the Web; HTML+.  Browser based Zoho and gDocs lack the completeness of a Web productivity environment capable of hosting the business processes currently bound to the Windows WorkGroup productivity environment. 

    There is no indication that the experts at Forrester understand what should be obvious.  

    excerpt: According to a new Forrester Research report, IT orgs are still choosing Microsoft Office over its competitors.  

    Two factors appear to be stumbling bloc
Gary Edwards

libOPC version 0.0.1 released - Doug Mahugh - Site Home - MSDN Blogs - 1 views

  •  
    Good review of Florian's work on the libOPC project!  Sadly i wrote a lengthy comment on this, but then made the mistake of sending it to Facebook where they clipped off 80% of what i had written.  Huge mistake on my part.  Facebook continues to piss me off in ever new and innovative ways.
Gary Edwards

Official Google Blog: Pagination comes to Google Docs - 0 views

  •  
    Although you need Chrome for the new Google Docs pagination feature, the key here is that gDocs now supports the CSS3 pagination module!  

    excerpt: Today, we're doing another first for web browsers by adding a classic word processing feature-pagination, the ability to see visual pages on your screen. We're also using pagination and some of Chrome's capabilities to improve how printing works in Google Docs.

    Native Printing:
    Pagination also changes what's possible with printing in modern browsers. We've worked closely with the Chrome team to implement a recent web standard, CSS3, so we can support a feature called native printing. Before, if you wanted to print your document we'd need to first convert it into a PDF, which you would then need to open and print yourself. With native printing, you can print directly from your browser and the printed document will always exactly match what you see on your screen.
1 - 20 of 495 Next › Last »
Showing 20 items per page