> 
> On 06/02/2015 11:59 AM, Arthur Schwarz wrote:
> 
> I haven't yet seen any pdf, so it's hard for me to state what you are
> referring to.
 
 
    Both .pdf and .odt files are included in this post.
 
> In particular, while .odt is a portable format, it is still a
> binary format 
 
    I found out yesterday that .odt files are zipped files - not binary. If
you unzip the .odt file there are several ASCII files and directories. In
truth, I have absolutely no idea what they are - or mean. It appears that
the text is in content.xml, but I haven't verified this.
 
> All I'm saying is that you can accelerate
> the acceptance of your work by making it in a format that is easier to
> incorporate.  We're not going to outright reject your work, just because
> we can't drop it in.  And if your work is truly as amazing as you are
> making it out to be, then someone else will step up and help in the
> transformation efforts.

On the other hand you will consider my work with due diligence until it is
converted, and haphazardly if it is not. So the labor of conversion is
complete before the process of acceptance is begun. That is the rub. (See
comments below on my 'amazing work'.)

> 
> > My document has tables and drawings. Something which seems missing from 
> 
> We'd be glad to help you learn how to incorporate figures into .texinfo.

I've spent 5 months on a task which I didn't enjoy to produce a product of
little interest. My entire objective in this effort was to learn enough so
that I can run a test. What I think I produced was a product to teach others
to perform testing with less effort.

> 
> It would also help to know what original source your drawings are in.

The drawing were done within Open Office using the Open Office tools. The
term 'drawing' is to be taken in the context of the Open Office application
which allows users to create 'drawings'.


> > 
> > So, if the intent is to say that the maintainers are not in a position
to
> > remove Section 15 and insert a new Section 15 then I think that we are
in a
> > pickle. 
> 
> Without even seeing the 'suggested' changes, it's hard to make any sort
> of judgment call.

The partial document is included (for TAP). The 'full' document is available
if you want it, but it is incomplete and unproofed (maybe 'unproved' would
be a better way of phrasing this, umm?).

> 
> I'm not trying to discourage you - by all means, PLEASE continue to
> contribute, and make the documentation better.  Free software is more
> powerful because anyone can scratch their itch, and your itch is the
> quality of documentation.  All I'm trying to do is to make you aware
> that you can't expect overnight adoption of your new work, especially if
> it is not yet in a format that will drop in place of the older text.

Thank you for the kind words. Just to 'set the record straight', whatever
that means, I am not so ego driven as to think that my work of stupendous
art is either stupendous or art. What I would like to think is that I
present a different viewpoint to an (un)willing audience, (1) a structure
showing the architectural outlines of a document, and (2) content which
shows the explication of the structure. I expect that if the document has
any provenance it will be critiqued, and the critique should address
structure, accuracy and content. The structural component is developed to
enable a user to look at the table of contents to get a 'feel' for the
contents, and to lead a user to understand how the Automake implementation
is structured. That is, if B is included in A then the document section
number should be A.B, subordination supports implementation. This does not
exist in the current Section 15. As to accuracy, I've tried. Nick Bowler
continuously questions my assumptions and is continuously correct in his
interpretations - drat.

> 
> I do
> not want to become the maintainer, but I can help shepherd patches in,
> provided that they do not become a time sink on my end.  That means that
> if I'm the one stuck transcribing .odt into .texinfo, it probably won't
> happen, but lack of my time should not be construed as rejection of your
> work.

I appreciate your thoughts. I completely agree with the notion of a 'time
sink'.

art (who develops amazing documents - true until critiqued otherwise)

> 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 
>