[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Community Documentation Architecture, was LaTeX templates, was Docmentation/FAQs



Since all of the code except for 3 lines or so is likely to be shared
with the preprocessing of plain text templates,  I guess the obvious
question is:

If you have an environment (like point of sale) where you need simple,
fixed width text templates, is there a case to be made to use XSLT,
when a simple preprocessor exists at the moment?  If there is not a
major one, why would we discontinue LaTeX as an option since it is
only a couple of additional lines?

I.e. what could you say to convince my point of sales customers that
they have to either learn XSLT to modify a simple text point of sale
receipt (not LaTeX, mind you, just plain text) or hire someone to do
that for them?  If there is no value propisition to drop the
preprocessing system, why drop the 3-4 lines of additional code
required to provide LaTeX as an option?

I understand that you favor XSLT, but advocating one thing is a quite
different matter from advocating the lack of support for something
else especially when little benefit would be found from dropping that
unless far more intrusive cuts were made (i.e. discontinuing support
for simple, plain text templates).

Best Wishes,
Chris Travers

On 9/30/06, Joshua D. Drake <..hidden..> wrote:

> Now regarding going with an all-XML template system, I think it is
> *WAY* too soon to even be considering this.  Furthermore, I don't
> think it to our benefit to suggest that people who move to our
> software will need to redo all their custom templates at this time.

Well my last email suggested a life span of 2 years for this. So we
would be supporting latex for at least that.

Secondly... ;) you want to bring people to our product? Then we need to
focus on a migration script for quickbooks. IMHO, the steps for
supported migrations need to be:

1. Support SQL-Ledger for as long as reasonably possible, I can't see
that being much longer then 6 months and then I would expect SQL-Ledger
to die a slow death after that. We have far too much momentum at this point.

2. Quickbooks. If you want people to use our product, lots of people we
need to replace quickbooks.

Joshua D. Drake





--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
             http://www.commandprompt.com/