>ok, do you understand that is comparing
>a converted .html file to a converted .pdf?

Yes, because in either case we are examining the possible *output* rendering file format *rendered results* currently accomplished by an advocate of a particular *input* encoding file format.  Assuming that a particular output formatting rendering software or hardware is available on a particular hardware machine.  My currently favorite hardware machine has built-in very good support for PDF, weak support for PG TXT, and little or no support for HTML (unless I read that HTML “on line” using the machine’s weak web browser)  So in practice, for a given hardware machine that I choose to use then the choice of output file rendering format becomes a non-issue – as long as the hardware machine supports it.  If the hardware machine doesn’t support it, then I have to find software that renders one output rendering file format to a different rendering file format [running that cross-rendering software on a difference machine which does support the cross-rendering software] – which ALMOST ALWAYS in practice causes considerable semantic loss of author’s original intent, plus excessive ugliness.  Which is why we would like a strong input encoding file format, one which is NOT overly concerned with how the ink get rendered on the display, so that we can avoid the problem of having to cross-render output rendering file formats.  As a reader, I no more care if HTML or PDF is the output rendering file format than in the choice of rendering graphics language the computer display card or embedded graphics chip eventually runs.  As a reader I just care how readable vs. how ugly the resulting ink on the display ends up.

>show me the "proper" markup to accomplish the mobi,
>and i will edit the template so you can get that markup.

I think what the “proper” markup is, is what we are trying to discuss.  MOBI, and EPUB, have a concept of a Spine, which requires information not typically included in current markups, such as proper identification of author first name, last name.  One possible markup from OPF showing one (pretty good imho) way this can be done is:

<dc:creator opf:file-as="King, Martin Luther Jr." opf:role="aut">

        Rev. Dr. Martin Luther King Jr.

</dc:creator>

This spine information is used, for example, to provide the reader the option of listing his/her books alphabetically by author last name.

And I am sure that someone is now sure to claim that automagical tools can be created to correctly extract this information, but I would hope that these famous author name examples would be enough to persuade you otherwise:

Sun Tzu

Miguel de Cervantes

Marquis de Sade

And I am sure someone else will claim that this information can automagically be provided by the PG database itself, but again perusal of how author names are currently being encoded in the PG database *ought* to be enough to dissuade people that spine information can be correctly provided automagically from that location.