Re: [xsl] where to look for xsl folk..

Subject: Re: [xsl] where to look for xsl folk..
From: "adam adam@xxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 3 Jul 2016 21:16:31 -0000
hey

Interesting.

I think the model I have in mind for publishing might evade these
problems. Im not looking for a magic want, rather Im anticipating some
of the structure will necessarily have to be applied by the publisher.
It marks a very interesting case where publishers, when empowered with
the right tools, can bring back total control of the doc inhouse and
stop the ridiculous workflows that have publishers throwing docx files
over the wall to vendors who do all the file conversion manually (which
is both expensive, time consuming, and fails when there is a need to
update the published outout).

adam
 

On 07/03/2016 02:09 PM, Graydon graydon@xxxxxxxxx wrote:
> On Sun, Jul 03, 2016 at 04:43:00PM -0000, adam adam@xxxxxxxxxxxxxxx scripsit:
>> i also ran a series of tests because i was particularly focused on
> Tests are good.
>
>> avoiding char loss. The tests looked good but if you have any cases where
>> you know char loss happens I'd be very interested to learn more ...
> I don't mean "character loss in the sense of something going silently
> wrong in the XSLT toolchain"[1]; I mean "loss in the sense of `not
> matching the special case we didn't know about'". (or "what we thought
> was covering all the cases in that complex XPath doesn't", and so on.)
> With a lot of input documents and complex formatting -- which may not be
> the case, but you mentioned academic formatting, which my biases expect
> to be worse than legal -- and cases of deliberate addition or deletion
> (list decoration being explicit instead of automatic, say; the word
> "chapter" in headings going from explicit to being supplied by a
> stylesheet, etc.) can make automatic checking very tricky.  And if the
> project lives for awhile, something that fixes today's bug can manage to
> ignore some elements in last quarter's input, should that ever be run
> again.
>
>
> -- Graydon
>
> [1] be very very careful of third party tools that write MS Office file
> formats, though.
> 

-- 

---
Adam Hyde
http://www.adamhyde.net/projects

Current Thread