On 6 Aug 2017, at 17:15, Hussein Shafie wrote:

On 08/06/2017 10:09 AM, Leif Halvard Silli wrote:
And that, in turn, means that I can just as well let XXE interface with
the local Google Drive folder on my harddisk. And thus, since I need
that app, the Google Drive plug in is not all that useful, even for
working with Google Drive.

XMLmind XML Editor - Using Google Drive™ as an XML Document Repository

1. Why use this add-on?

3. Teamwork on the Google Drive

4. Working with revisions (or “who did what and when?”)

Those instructions were very useful to us when we first started to use XXE+Google Drive for our HTML-based book projects (see below).

However, if the Google Drive plug-in is not useful to anyone, we'll be glad to discontinue it. Less code to maintain. Less end-user support.

Let me give you a more nuanced picture of our experience, then.

It would have been nice and useful to use both the Google Drive plug-in **and** the Google Drive App, if only the Google Drive App was not so annoying for the type of output that the XXE DITA and Docbook conversion creates. But the fact that Dropbox handles numerous small files better does not mean that it is a good authoring strategy to keep regenerating the same numorous icon files, over and over ... !

Thus, there are two things XML Mind could do with XXE so that the Google Drive experience - and even the day to day Docbook and DITA experience - would become less annoying:

1. The XXE HTML-conversion tools could be made to generate the navigation icon files only once - instead of generating them on every single conversion. 2. The XXE HTML-conversion tools could, instead of a single image file for each button, switch to generate a single CSS sprite (a single, combined, image file with all the navigation icons) for all the navigation buttons.

I can say that I have found the Google Drive plug-in quite useful when working on XHTML files. For instance, we have two books made as XHTML files which are glued together via XInclude. (We combined XXE’s Google Drive plug-in with the Google Drive app.) And I believe that one reason why it worked quite well in that case was that, when one is working on XHTML files, one is working on the end product. Thus I have control over the number of image files that get created. Plus that the images, in such a case, is not regenerated over and over. (We still work on those books, and thus we will probably continue to use Google Drive plug-in and app the same way, for those projects.)

But when working with DocBook or DITA, the situation is unfortunately different. The last step - namely conversion to HTML - causes numerous navigation icon files to be created. And this happens over and over - on every conversion. Even if, as far as I can tell, for all the icon files, the date is the only thing that changes).

On the Web, numerous small images is a bad authoring practise that causes Web pages to load more slowly. Therefore, for the Web, the technique called “CSS sprites” have been developed. As W3Schools explains, an CSS sprite is [”a collection of images put into a single image”](https://www.w3schools.com/css/css_image_sprites.asp). Thus, instead of many small images, the browser loads a larger image consisting of many smaller images. Via CSS, only the relevant part of the image is displayed. This implies using CSS background images instead of pointing directly to the image via the @src attribute of an <img> element. (I am no expert at creating sprites my self - I just know the basic technique.)

Even when generating documents on a harddisk, it takes considerable more time to generate numerous small images compared with a single larger one. An even faster solution would be if the image would be generated only on the first generation - and not on the subsequent generations. (In fact, two only generate the images on the first conversion would *considerably* bring down the synchronization activity of Google Drive!)

I am mentioning this because there are several issues that contribute to how well or bad the user experience turns out. If the XXE conversion functionality for DITA and Docbook had, for its HTML output, used CSS sprites instead of <img> images for its navigation buttons, there should be a massive speed gain when syncing (via the Google Drive app). Such a thing should also bring a considerable speed bump during the conversion process - it would be good even for non-Google Drive users.

I realize that for the Docbook conversion, you rely on the ’official’ XSL stylesheets - which do not use CSS sprites. But perhaps you could switch to CSS sprites for the DITA conversion ... ?

Btw, for Web sites, in general, my Web page design tool has, for many years, been an application which defines itself as a HTML generator which includes a SFTP tool for FTP-ing the files to the Web site. And I know that that particular app - which generates both image files, CSS files and HTML files - keeps a small 'file list file' where it maintains a list over all the generated files of the site. And then, as the app is syncing/FTP-ing the files to the Web server, the app will first compare the 'file list file' stored on the Web server with the 'file list file' stored locally. The app will then only upload files that have changed. (I believe that change of date does not count as 'changed'.) I do not know if there is anything to learn from that practise ...

Leif Halvard Silli
XMLmind XML Editor Support List

Reply via email to