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?
http://www.xmlmind.com/xmleditor/_distrib/doc/gdrive/why_use_it.html
3. Teamwork on the Google Drive
http://www.xmlmind.com/xmleditor/_distrib/doc/gdrive/teamwork.html
4. Working with revisions (or “who did what and when?”)
http://www.xmlmind.com/xmleditor/_distrib/doc/gdrive/working_with_revisions.html
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
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
