The primary advantage is that Latex -> PDF tools exist, freely and reliably; it's also well-known and reams of documentation exist. A subsidiary advantage is that Latex would be translatable into other formats, if so needed 'down the road'. Another subsidiary advantage is that typesetting is largely managed by Other People Whose Code We Don't Have To Debug.
There *are* other tools to take text & images and convert to PDF. I would be surprised, however, if they are are as well known, debugged or as good in licensing for DW.
Let me toss some thoughts down in a more formal fashion about how this would have to look.
I would expect the architecture to follow this model in some fashion.
Journal DB -> Reformatter -> PDF Generator
The reformatter will be putting the journal into a paperable form suitable for the PDF generator to receive it. Possibly the reformatter will manage some of the filtering options as well. A filter block might be suitable further up the pipe.
The PDF generator will come in one of several flavors; roll-your-own, use external library(e.g., CPAN's PDF exporters), use latexy tool that adds a new step in the process, possibly allowing output in non-pdf formats as well.
Suppose we have some kind of filter block and use latex:
DB -> Filter -> Reformatter -> Latex Generator-> Latex/PDF generator.
The filter will be managing queries and ensuring that only the 'right' data comes through.
The reformatter will be doing such things as large comment thread management, image management, etc.
The latex generator will be reading the "ready-to-go" data and outputting a Latex text document that has the content.
Of course, latex itself can produce final output in pdf, html, man(prob-ably not needed), and I expect it to continue being able to output in whatever formats come onto the scene and are widely accepted.
Yet, I see some basic challenges with my idea:
1. Latex. It's mind-blowingly annoying at times and requires Yet Another set of highly specialized knowledge.
2. Latex. It's not the most general thing on the market without modifications. What happens if we get a group of non-English users? Document handling for them has to come into being then.
3. Latex. It's a sledgehammer. Is the problem a screw? It'll still Jam The Widget Into The Thingie, but maybe it's not quite the right kind of jamming that a screwdriver will provide.
no subject
reliably; it's also well-known and reams of documentation exist. A
subsidiary advantage is that Latex would be translatable into other
formats, if so needed 'down the road'. Another subsidiary advantage is
that typesetting is largely managed by Other People Whose Code We
Don't Have To Debug.
There *are* other tools to take text & images and convert to PDF. I
would be surprised, however, if they are are as well known, debugged
or as good in licensing for DW.
Let me toss some thoughts down in a more formal fashion about how this
would have to look.
I would expect the architecture to follow this model in some fashion.
Journal DB -> Reformatter -> PDF Generator
The reformatter will be putting the journal into a paperable form
suitable for the PDF generator to receive it. Possibly the
reformatter will manage some of the filtering options as well. A
filter block might be suitable further up the pipe.
The PDF generator will come in one of several flavors; roll-your-own,
use external library(e.g., CPAN's PDF exporters), use latexy tool that
adds a new step in the process, possibly allowing output in non-pdf
formats as well.
Suppose we have some kind of filter block and use latex:
DB -> Filter -> Reformatter -> Latex Generator-> Latex/PDF generator.
The filter will be managing queries and ensuring that only the 'right'
data comes through.
The reformatter will be doing such things as large comment thread
management, image management, etc.
The latex generator will be reading the "ready-to-go" data and
outputting a Latex text document that has the content.
Of course, latex itself can produce final output in pdf, html,
man(prob-ably not needed), and I expect it to continue being able to
output in whatever formats come onto the scene and are widely
accepted.
Yet, I see some basic challenges with my idea:
1. Latex. It's mind-blowingly annoying at times and requires Yet
Another set of highly specialized knowledge.
2. Latex. It's not the most general thing on the market without
modifications. What happens if we get a group of non-English users?
Document handling for them has to come into being then.
3. Latex. It's a sledgehammer. Is the problem a screw? It'll still Jam
The Widget Into The Thingie, but maybe it's not quite the right kind
of jamming that a screwdriver will provide.