Generating PDFs with Ada

Generating PDFs with Ada

[R. Tyler Croy]

I have a project idea in my head that I'd /like/ to build with Ada rather than
Python but I can't seem to find a library for generating PDF files with Ada.

Does such a beast exist?


-- 
- R. Tyler Croy
--------------------------------------
    Code: http://github.com/rtyler

Re: Generating PDFs with Ada

[Pascal Obry]

Le 09/01/2011 02:00, R. Tyler Croy a écrit :
> I have a project idea in my head that I'd /like/ to build with Ada rather than
> Python but I can't seem to find a library for generating PDF files with Ada.
> 
> Does such a beast exist?

Depending on the actual project, why not generate Latex and call
pdflatex to generate the PDF?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Generating PDFs with Ada

[Dmitry A. Kazakov]

On 09 Jan 2011 01:00:55 GMT, R. Tyler Croy wrote:

> I have a project idea in my head that I'd /like/ to build with Ada rather than
> Python but I can't seem to find a library for generating PDF files with Ada.
> 
> Does such a beast exist?

Cairo has PDF surfaces. A surface in Cairo is the backend where the drawing
goes. So you can paint and write texts directly into a PDF file from Ada
using cairoada bindings. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Generating PDFs with Ada

[leonid]

On Jan 9, 11:43 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On 09 Jan 2011 01:00:55 GMT, R. Tyler Croy wrote:
>
> > I have a project idea in my head that I'd /like/ to build with Ada rather than
> > Python but I can't seem to find a library for generating PDF files with Ada.
>
> > Does such a beast exist?
>
> Cairo has PDF surfaces. A surface in Cairo is the backend where the drawing
> goes. So you can paint and write texts directly into a PDF file from Ada
> using cairoada bindings.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

qtada (http:/users1.jabry.com/adastudio/index.html) supports all
document formats
Leonid

Re: Generating PDFs with Ada

[Gautier write-only]

On Jan 9, 2:00 am, "R. Tyler Croy" wrote:

> I have a project idea in my head that I'd /like/ to build with Ada rather than
> Python but I can't seem to find a library for generating PDF files with Ada.
>
> Does such a beast exist?

Not that I know.
From time to time I am tempted to make a standalone "PDF Writer" in
the fashion of Excel Writer ( http://excel-writer.sf.net/ ),
eventually using existing sources. Did not find a real incentive or
personal or professional need up to now.
You can begin with the basic and essential features, avoid other ones
like compression, and stick to PDF 1.2, you probably you get something
usable within a few days - it was the case for Excel Writer. Easier to
do than what one could thing and it is very satisfying to see the
result.
If it can help too, there is a PostScript generator there:
http://sf.net/projects/mathpaqs/ , in the ./graph directory.
HTH
______________________________________________________________________________
Gautier's Ada programming -- http://gautiersblog.blogspot.com/search/label/Ada
NB: follow the above link for a working e-mail address

Re: Generating PDFs with Ada

[Stephen Leake]

Pascal Obry <pascal@obry.net> writes:

> Le 09/01/2011 02:00, R. Tyler Croy a écrit :
>> I have a project idea in my head that I'd /like/ to build with Ada rather than
>> Python but I can't seem to find a library for generating PDF files with Ada.
>> 
>> Does such a beast exist?
>
> Depending on the actual project, why not generate Latex and call
> pdflatex to generate the PDF?

I considered that path once for building better PDF versions of the Ada
language reference manual. I concluded it was not any easier than
generating the PDF in the first place.

I suppose it depends on how complex your document is.

-- 
-- Stephe

Re: Generating PDFs with Ada

[Yannick Duchêne (Hibou57)]

Le Mon, 10 Jan 2011 03:29:00 +0100, Stephen Leake  
<stephen_leake@stephe-leake.org> a écrit:
> I considered that path once for building better PDF versions of the Ada
> language reference manual. I concluded it was not any easier than
> generating the PDF in the first place.
>
> I suppose it depends on how complex your document is.
Also I feel LaTeX and its typical utilities are not that much Unicode  
ready (although Unicode is already 20 years old exactly this year).  
Writing PDF at the first place is better for that reason at least.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Generating PDFs with Ada

[Georg Bauhaus]

On 10.01.11 04:48, Yannick Duchêne (Hibou57) wrote:
> Le Mon, 10 Jan 2011 03:29:00 +0100, Stephen Leake
> <stephen_leake@stephe-leake.org> a écrit:
>> I considered that path once for building better PDF versions of the Ada
>> language reference manual. I concluded it was not any easier than
>> generating the PDF in the first place.
>>
>> I suppose it depends on how complex your document is.
> Also I feel LaTeX and its typical utilities are not that much Unicode ready
> (although Unicode is already 20 years old exactly this year). Writing PDF at
> the first place is better for that reason at least.

Another approach is to rely on existing standards and tools:
produce input suitable for PDF rendering via XSL FO.
Control the process from within your Ada program.

OK, that's less sexy than writing NIH software.

Re: Generating PDFs with Ada

[Yannick Duchêne (Hibou57)]

Le Mon, 10 Jan 2011 11:19:01 +0100, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
> Another approach is to rely on existing standards and tools:
> produce input suitable for PDF rendering via XSL FO.
> Control the process from within your Ada program.
Do know and use XSL, but not XSL-FO. However the web seems to agree with  
that point.

English: “The most common and best supported print output is currently  
Adobe PDF”
http://www.learn-xsl-fo-tutorial.com/

French: « XSL-FO (Formatting Objects) est l’outil de prédilection pour  
générer du PDF »
http://dosimple.ch/articles/Introduction_XSL-FO/

Thanks for the tip!

> OK, that's less sexy than writing NIH software.
National Institutes of Health ? (oops)

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Generating PDFs with Ada

[Adam Beneschan]

On Jan 8, 5:00 pm, "R. Tyler Croy" <ty...@linux.com> wrote:
> I have a project idea in my head that I'd /like/ to build with Ada rather than
> Python but I can't seem to find a library for generating PDF files with Ada.
>
> Does such a beast exist?

As long as we're on sort of a similar subject, I've wondered several
times if there are Ada libraries for creating Microsoft Word
documents.

                              -- Adam

Re: Generating PDFs with Ada

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:9f23e50a-2c2c-4ccc-bd56-f6ffdc6c7ee7@37g2000prx.googlegroups.com...
>On Jan 8, 5:00 pm, "R. Tyler Croy" <ty...@linux.com> wrote:
>> I have a project idea in my head that I'd /like/ to build with Ada rather 
>> than
>> Python but I can't seem to find a library for generating PDF files with 
>> Ada.
>>
>> Does such a beast exist?
>
>As long as we're on sort of a similar subject, I've wondered several
>times if there are Ada libraries for creating Microsoft Word
>documents.

The output module for the Ada Reference Manual formatter can create .rtf 
files (as well as .html files). It doesn't support anything not needed in 
the various Standards, but that still is quite a bit. I rather wish I had 
designed it a bit more flexibly so that the formats were not quite so firmly 
defined. Still, it would make a decent start in that direction.

The ARM Formatter is supposed to be licensed as GPL software (it will be as 
soon as I get a round tuit).

                                      Randy.

Re: Generating PDFs with Ada

[Stephen Leake]

Adam Beneschan <adam@irvine.com> writes:

> On Jan 8, 5:00 pm, "R. Tyler Croy" <ty...@linux.com> wrote:
>> I have a project idea in my head that I'd /like/ to build with Ada rather than
>> Python but I can't seem to find a library for generating PDF files with Ada.
>>
>> Does such a beast exist?
>
> As long as we're on sort of a similar subject, I've wondered several
> times if there are Ada libraries for creating Microsoft Word
> documents.

I hope not :)

-- 
-- Stephe

Re: Generating PDFs with Ada

[Adam Beneschan]

On Jan 11, 12:51 am, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:

> > As long as we're on sort of a similar subject, I've wondered several
> > times if there are Ada libraries for creating Microsoft Word
> > documents.
>
> I hope not :)

Why?  (Maybe I shouldn't pursue this, but I've gotten curious about
what the thinking is behind this sort of answer.)

                             -- Adam

Re: Generating PDFs with Ada

[Ludovic Brenta]

Adam Beneschan writes:
> On Jan 11, 12:51 am, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>
>> > As long as we're on sort of a similar subject, I've wondered several
>> > times if there are Ada libraries for creating Microsoft Word
>> > documents.
>>
>> I hope not :)
>
> Why?  (Maybe I shouldn't pursue this, but I've gotten curious about
> what the thinking is behind this sort of answer.)

Because Microsoft Word is proprietary and uses a non-standard,
proprietary and ever-changing format (think "planned obsolescence").
Even the more recent so-called "Open XML" format contains many parts
that are not in the public spec, making it anything but "open".

You are a proponent of Ada.  One of the selling points of the language
is that it is not only an official ISO standard but an open one at that.
Microsoft formats are neither official ISO standards nor open.  In
contrast:

PDF/A, appropriate for immutable content, is ISO 19005-1:2005;
OpenDocument, appropriate for mutable content, is ISO/IEC 26300:2006;
full PDF 1.7 is ISO 32000-1:2008.

-- 
Ludovic Brenta.

Re: Generating PDFs with Ada

[Yannick Duchêne (Hibou57)]

Le Tue, 11 Jan 2011 19:41:13 +0100, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:
> You are a proponent of Ada.  One of the selling points of the language
> is that it is not only an official ISO standard but an open one at that.
> Microsoft formats are neither official ISO standards nor open.  In
> contrast:
True. The only exception to this is the ECMA-234 standard for the basic MS  
Windows API.
http://www.ecma-international.org/publications/standards/Ecma-234.htm

Otherwise trying to get relevant documentation about the Word format is a  
nightmare (and these documentations are mostly hackings, reverse  
engineering and the like). And it is the same since long.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Generating PDFs with Ada

[Adam Beneschan]

On Jan 11, 10:41 am, Ludovic Brenta <ludo...@ludovic-brenta.org>
wrote:
> Adam Beneschan writes:
> > On Jan 11, 12:51 am, Stephen Leake <stephen_le...@stephe-leake.org>
> > wrote:
>
> >> > As long as we're on sort of a similar subject, I've wondered several
> >> > times if there are Ada libraries for creating Microsoft Word
> >> > documents.
>
> >> I hope not :)
>
> > Why?  (Maybe I shouldn't pursue this, but I've gotten curious about
> > what the thinking is behind this sort of answer.)
>
> Because Microsoft Word is proprietary and uses a non-standard,
> proprietary and ever-changing format (think "planned obsolescence").
> Even the more recent so-called "Open XML" format contains many parts
> that are not in the public spec, making it anything but "open".
>
> You are a proponent of Ada.  One of the selling points of the language
> is that it is not only an official ISO standard but an open one at that.
> Microsoft formats are neither official ISO standards nor open.

So what?  Does "being a proponent of Ada" necessarily imply "being a
proponent of users ditching all their proprietary, non-ISO, non-open
stuff and changing their entire computing environment to fit some
'openness' paradigm"?  I sure don't see it.

There are a lot of Windows users out there.  There are Ada compilers
targeted to Windows (or do you object to that?).  Many of those
Windows users use tools like Microsoft Office.  Do you believe that
the Ada community should tell them, "Sorry, those tools aren't based
on ISO standards, so Ada isn't for you"?  I thought we were trying to
encourage the spread of the Ada language.  And I'm sure there are
other tools out there (besides MS Office) that generate .doc files.
Do we intend to tell those tools' authors, "Ada would be a great
language for writing your tool--it would make your tool more robust
and easier to maintain--but we don't want you to use it because you're
generating something that has a proprietary format, so please use C++
instead"?  Why???

As for Microsoft using a "non-standard, proprietary and ever-changing
format", there seems to be some format information available at

http://www.microsoft.com/interop/docs/officebinaryformats.mspx

How often this changes, I don't know, but they do have an interest in
keeping things compatible, so something written according to this
format would (I would think) work with any version of Microsoft Word
for a number of years, at least, even if the format specification
doesn't include all the latest features.  (I notice that it's a
specification for .doc files but there may not a public one
for .docx).  Still, I think that, at least hypothetically, this format
information could be used to write a useful tool that generates a Word
file, if one decided that it was necessary.

It may be that the need for writing a Word document is small enough
that nobody has considered it worth their while to write a library
like that.  I can accept that as a reason.  But the attitude that I
thought I detected---"I hope [that nobody writes a library like
that]"---is not one that I believe serves the Ada community.  I
apologize if I read too much into anything anyone said.

                                     -- Adam

Re: Generating PDFs with Ada

[Yannick Duchêne (Hibou57)]

Le Tue, 11 Jan 2011 21:47:58 +0100, Adam Beneschan <adam@irvine.com> a  
écrit:
> So what?  Does "being a proponent of Ada" necessarily imply "being a
> proponent of users ditching all their proprietary, non-ISO, non-open
> stuff and changing their entire computing environment to fit some
> 'openness' paradigm"?  I sure don't see it.
Yes.

> http://www.microsoft.com/interop/docs/officebinaryformats.mspx
Good, this leads me to this:
http://msdn.microsoft.com/en-us/library/ff381461.aspx
http://msdn.microsoft.com/en-us/library/dd208104.aspx

Mmmh, this, should not be missed:
> Microsoft Open Specification Promise
> Published: September 12, 2006 | Updated: February 1, 2007
> --
> Microsoft irrevocably promises not to assert any Microsoft Necessary
> Claims against you for making, using, selling, offering for sale,
> importing or distributing any implementation to the extent it
> conforms to a Covered Specification (“Covered Implementation”),
> subject to the following. This is a personal promise directly from
> Microsoft to you, and you acknowledge as a condition of benefiting
> from it that no Microsoft rights are received from suppliers,
> distributors, or otherwise in connection with this promise. If you
> file, maintain or voluntarily participate in a patent infringement
> lawsuit against a Microsoft implementation of such Covered
> Specification, then this personal promise does not apply [...]
Source: http://www.microsoft.com/interop/osp/default.mspx

In less words, if you want to be friend with MS, you have to not sue them  
;)


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Generating PDFs with Ada

[Ludovic Brenta]

Adam Beneschan writes on comp.lang.ada:
> There are a lot of Windows users out there.  There are Ada compilers
> targeted to Windows (or do you object to that?).  Many of those
> Windows users use tools like Microsoft Office.  Do you believe that
> the Ada community should tell them, "Sorry, those tools aren't based
> on ISO standards, so Ada isn't for you"?

No, I think we should tell them "tools should generate PDF or
OpenDocument, not a proprietary format"; this is true whatever language
the tools are written in.

BTW, I object to the use of Microsoft Word or any word processor for
professional documents in the first place.  Professional document
management requires:

* separation of form from content (documents should not contain the
  definition of styles; they should point to shared style sheets).

* compatibility with multiple (current and future) professional version
  control systems providing the ability to branch, merge and tag
  versioned documents and versioned style sheets by multiple people at
  the same time; the only format which in my experience has this
  property is Plain Text, possibly with markup!

* compatibility with multiple (current and future) editors and viewers
  on multiple (current and future) platforms; think of legal
  requirements that documents be readable 100 years from now, and the
  fact that the only extant documents that have proven to have this
  property are on paper, parchment or papyrus.

* compatibility with search and indexing software.

* compatibility with cryptographic signatures, for authentication of
  documents

* compatibility with multiple encryption algorithms, current and future,
  for secrecy.

> I thought we were trying to encourage the spread of the Ada language.

The only correlation between Ada and PDF is that both are ISO standards
and that being an ISO standard is a Good Thing(tm); other than that the
case against proprietary formats is independent on the implementation
language of tools.

> And I'm sure there are other tools out there (besides MS Office) that
> generate .doc files.

Apart from Microsoft's own, I can't think of any such tool.  Then again,
I don't use office software much, I don't use Windows, and I would
certainly not use, much less buy, a tool that locks my data into a
proprietary format like .doc.  Maybe that's because I'm a software
engineer and not a lemming :)

> Do we intend to tell those tools' authors, "Ada would be a great
> language for writing your tool--it would make your tool more robust
> and easier to maintain--but we don't want you to use it because you're
> generating something that has a proprietary format, so please use C++
> instead"?  Why???

Ah, but I don't think C++ would make it any easier for them to generate
.doc files than Ada would.  Quite the contrary, in fact :)

> As for Microsoft using a "non-standard, proprietary and ever-changing
> format", there seems to be some format information available at
>
> http://www.microsoft.com/interop/docs/officebinaryformats.mspx

OK.

> How often this changes, I don't know, but they do have an interest in
> keeping things compatible,

This is only half true.  Their interest is to make their software
backward compatible (to ease migration to newer versions of their
software) but forward incompatible (to *force* migration to newer
versions of their software, aka planned obsolescence, and break
competitors' tools, aka total dominance).  The only reason why they have
published some specifications (the "Microsoft Open Specification
Promise") is because "open" has become a buzzword and they want to be
"buzzword compliant" and combat the rise of actual open standards.
Remember: standards exist to protect customers against greedy vendors,
not the opposite.  Me, I'll choose a Standard over a Promise every time.

> so something written according to this format would (I would think)
> work with any version of Microsoft Word for a number of years, at
> least, even if the format specification doesn't include all the latest
> features.  (I notice that it's a specification for .doc files but
> there may not a public one for .docx).  Still, I think that, at least
> hypothetically, this format information could be used to write a
> useful tool that generates a Word file, if one decided that it was
> necessary.

Technically, this is true; but generating PDF or OpenDocument is a
better alternative, and not more difficult than generating .doc. (BTW,
.doc is not a single format, it is a series of incompatible formats
dating back to circa 1989, only the last of which has been published).

> It may be that the need for writing a Word document is small enough
> that nobody has considered it worth their while to write a library
> like that.  I can accept that as a reason.  But the attitude that I
> thought I detected---"I hope [that nobody writes a library like
> that]"---is not one that I believe serves the Ada community.  I
> apologize if I read too much into anything anyone said.

Like Stephe, I too hope that nobody writes a library that helps generate
.doc files.  My reason reason is that such a tool would endorse the
proprietary format and help continue the dominance of evil proprietary
formats against standard ones.  The same tool could be just as useful
writing PDF, DocBook, OpenDocument or even Plain Text instead of any
version of .doc.  Software engineers should promote standards whenever
possible, whatever language they use.

-- 
Ludovic Brenta.

Re: Generating PDFs with Ada

[Yannick Duchêne (Hibou57)]

Le Tue, 11 Jan 2011 21:47:58 +0100, Adam Beneschan <adam@irvine.com> a  
écrit:
> As for Microsoft using a "non-standard, proprietary and ever-changing
> format", there seems to be some format information available at
>
> http://www.microsoft.com/interop/docs/officebinaryformats.mspx

Well, let's go for more, as it's somewhat the topic and as Ada novelists  
enjoy specifications a lot. An extract of my bookmarks on the topic of  
data formats in the large:

http://www.fileinfo.com/
http://www.fileformat.info/index.htm
http://www.wotsit.org/
http://www.iana.org/assignments/media-types/
http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html
http://fret.sourceforge.net/
http://www.astro.keele.ac.uk/oldusers/rno/Computing/File_magic.html
http://sourceware.org/gdb/current/onlinedocs/stabs.html#SEC_Top
http://www.fileformat.info/mirror/egff/index.htm
http://www.martinreddy.net/gfx/
http://www.fileformat.info/format/bmp/egff.htm
http://www.edm2.com/0107/os2bmp.html
http://www.library.cornell.edu/preservation/tutorial-french/presentation/table7-1.html
(the last is French only, sorry)

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Generating PDFs with Ada

[Yannick Duchêne (Hibou57)]

Le Tue, 11 Jan 2011 23:14:12 +0100, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:
> No, I think we should tell them "tools should generate PDF or
> OpenDocument, not a proprietary format"; this is true whatever language
> the tools are written in.
You could also be more pragmatic and note:
1) The amount of MS Windows and MS Applications users is great.
2) You are unlikely to convince them all.
3) If you convince some, the count of others will still be great.

What about advocating while supporting the actual state of thing ? You can  
do “I am able in some limits to provide support for this and that, but be  
warned that ... and what about .... and did you ever minded that ... ?”

Last but not least, anything widely used is near to always end into a  
de-facto standard. There may be planned obsolescence (I hate it as much as  
you do), but older format are still there and being more documented over  
the time.

Look at MIDI specification as an example: its not open at all, there is no  
publicly accessible official documentation about it, but as it exist since  
long, it is documented in multiple place in a way which make it really  
usable.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Generating PDFs with Ada

[Ludovic Brenta]

"Yannick Duchêne (Hibou57) writes on comp.lang.ada:
> Le Tue, 11 Jan 2011 23:14:12 +0100, Ludovic Brenta
> <ludovic@ludovic-brenta.org> a écrit:
>> No, I think we should tell them "tools should generate PDF or
>> OpenDocument, not a proprietary format"; this is true whatever language
>> the tools are written in.
> You could also be more pragmatic and note:
> 1) The amount of MS Windows and MS Applications users is great.
> 2) You are unlikely to convince them all.
> 3) If you convince some, the count of others will still be great.
>
> What about advocating while supporting the actual state of thing ? You
> can do “I am able in some limits to provide support for this and that,
> but be  warned that ... and what about .... and did you ever minded
> that ... ?”

That's exactly the attitude I've had with customers before.  So far I
have always been able to convince them not to use .doc, and therefore
I've never written any tool that generates .doc :)

> Last but not least, anything widely used is near to always end into a
> de-facto standard. There may be planned obsolescence (I hate it as
> much as you do), but older format are still there and being more
> documented over the time.

Whether a standard is "de facto" or "de jure" is irrelevant, the
relevant part is that a standard is not controlled by any single
(dominant) vendor.

> Look at MIDI specification as an example: its not open at all, there
> is no publicly accessible official documentation about it, but as it
> exist since long, it is documented in multiple place in a way which
> make it really usable.

That's because of multiple, independent implementations of the standard,
i.e. the situation is the opposite of that of .doc.

-- 
Ludovic Brenta.

Re: Generating PDFs with Ada

[Yannick Duchêne (Hibou57)]

Le Tue, 11 Jan 2011 23:14:12 +0100, Ludovic Brenta  
<ludovic@ludovic-brenta.org> a écrit:
> * separation of form from content (documents should not contain the
>   definition of styles; they should point to shared style sheets).
>
> * compatibility with multiple (current and future) professional version
>   control systems providing the ability to branch, merge and tag
>   versioned documents and versioned style sheets by multiple people at
>   the same time; the only format which in my experience has this
>   property is Plain Text, possibly with markup!
>
> * compatibility with multiple (current and future) editors and viewers
>   on multiple (current and future) platforms; think of legal
>   requirements that documents be readable 100 years from now, and the
>   fact that the only extant documents that have proven to have this
>   property are on paper, parchment or papyrus.
>
> * compatibility with search and indexing software.
>
> * compatibility with cryptographic signatures, for authentication of
>   documents
>
> * compatibility with multiple encryption algorithms, current and future,
>   for secrecy.

You must enjoy markup languages a lot so (XML, HTML, and the like).

> I don't use office software much, I don't use Windows, and I would

Neither I am, I feel this is too much presentation-oriented (and not  
enough semantic-oriented, as you noted). Moreover, these presentation  
oriented tools are more resource (hardware resources) and time (user time)  
consuming than what semantic-oriented editing is.

But this is still the major case: people use office applications and want  
to use office applications. Presentation can be as a support of  
expression, and in the presentation area, MS Office is one of the most  
well know and used.

Personal note: if you really want presentation and ease of creation and  
use and resilience, HTML+CSS (+SVG, optionally) is really the best. It  
happens sometime I wonder why people use so many different heavy formats  
while there is such a powerful and simple single one (and it can even be  
made dynamic for user interaction).

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Generating PDFs with Ada

[Shark8]

> BTW, I object to the use of Microsoft Word or any word processor for
> professional documents in the first place.  Professional document
> management requires:
>
> * separation of form from content (documents should not contain the
>   definition of styles; they should point to shared style sheets).
>
> * compatibility with multiple (current and future) professional version
>   control systems providing the ability to branch, merge and tag
>   versioned documents and versioned style sheets by multiple people at
>   the same time; the only format which in my experience has this
>   property is Plain Text, possibly with markup!
>
> * compatibility with multiple (current and future) editors and viewers
>   on multiple (current and future) platforms; think of legal
>   requirements that documents be readable 100 years from now, and the
>   fact that the only extant documents that have proven to have this
>   property are on paper, parchment or papyrus.
>
> * compatibility with search and indexing software.
>
> * compatibility with cryptographic signatures, for authentication of
>   documents
>
> * compatibility with multiple encryption algorithms, current and future,
>   for secrecy.

Interesting, I know Wordperfect's WPD format addresses, quite well,
points 1 & 3.
WP has/had a file Indexer *way* before version 11, addressing point 4.
As for Points 5 & 6, WP's had encryption and signing since at least
version 11.
Version 2 is, perhaps, the only one missing... and even that might be
debatible*.

And it is a stable format: "Files created in WordPerfect 6.x, through
12 are structured the same, and will hereafter be referred to as WP12
files." -- http://www.corelconnected.com/html/files/WPFF_!DocumentStructure.htm

"A key to WordPerfect's design is its streaming code architecture that
parallels the formatting features of HTML and Cascading Style Sheets."
-- http://en.wikipedia.org/wiki/WordPerfect

*From my WP11 Help-file:
COLLABORATING ON A DOCUMENT
It is often helpful to get opinions about a document before you send
it to a wider audience. You can email the document to friends, co-
workers, and editors for comments. The Review Document feature lets
reviewers redline, highlight, and comment on your text. Use Document
Compare to gather all the selected changes. If you must keep multiple
copies of the same file, use Corel Versions to archive each one for
reference.

COMPARING DOCUMENTS
You can compare a current version of a document with an earlier
version to see what changes have been made. When comparing documents,
you can generate a compare summary and a list of changes. A compare
summary describes the color and the attributes used to display
deletions and insertions. It also lists the number of deletions,
insertions, and moves that were made. The list of changes details all
of the changes made in the document.

When you compare and review a document, the document that contains the
comparison markings is opened in review mode. For more information
about reviewing documents, see "Reviewing documents." In addition, you
can restore a document to the way it was before the comparison.

Re: Generating PDFs with Ada

[Maciej Sobczak]

On Jan 11, 9:51 am, Stephen Leake <stephen_le...@stephe-leake.org>
wrote:

> > As long as we're on sort of a similar subject, I've wondered several
> > times if there are Ada libraries for creating Microsoft Word
> > documents.
>
> I hope not :)

Without getting involved into the discussion that follows, I would
propose everybody to read this:

http://www.joelonsoftware.com/items/2008/02/19.html

The most important part starts with "Let Office do the heavy work for
you", but the whole article is worth reading.

Some years ago I have been working on the application that was
supposed to produce Excel documents. I have done it via COM interfaces
and consider it to be the only reasonable solution for this kind of
tasks.
The file format might be non-standard, intentionally obfuscated, evil
and whatever you call it, but the API is documented and works very
well. Reimplementing the internal file format engine is pointless if
the document can be already produced at the level of its logical
content.

Now, the question is how to access COM interfaces from Ada, but I
believe this problem is already solved, as it is much more generic
than producing Word files.

The article describes alternative solutions as well, but none of them
is even close to writing Word files directly.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Re: Generating PDFs with Ada

[Pascal Obry]

Adam,

I think Ludivic concerns are not in the tool itself but the data. I was
a Windows user, I want to use the best tool to do the job (being free or
propietary - I paid for Lightroom as there is no equivalent in the Open
Source domain at the moment). As I said no problem.

But when I have the choice I won't be using a tool that also makes all
my data proprietary. The data are mine, why should I pay year after year
to be able to use them? I've spent hours on typing guitar partitions,
the tools is not there anymore, I've lost everything (true story), I had
made many documents using Word hopefully there is some free tool to read
this format otherwise I would have lost everything too. Likewise with
Excel, I've also lost genealogy work done on a proprietary tool... I
won't even try to count how many hours I've lost with all those tools :(

Let's take Lightroom that I'm using at the moment. The data to develop
the photos are so tied to Lightroom that I will probably have to keep
Lightroom forever :( I know but today I have no choice, it is a shame
but I need to get the job done...

So all in all I fully agree with Ludovic, be sure to use, whenever it is
possible, free and standard formats.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Generating PDFs with Ada

[Stephen Leake]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

>
> This is only half true.  Their interest is to make their software
> backward compatible (to ease migration to newer versions of their
> software) but forward incompatible (to *force* migration to newer
> versions of their software, aka planned obsolescence, and break
> competitors' tools, aka total dominance).  The only reason why they have
> published some specifications (the "Microsoft Open Specification
> Promise") is because "open" has become a buzzword and they want to be
> "buzzword compliant" and combat the rise of actual open standards.
> Remember: standards exist to protect customers against greedy vendors,
> not the opposite.  Me, I'll choose a Standard over a Promise every time.

+10

> Like Stephe, I too hope that nobody writes a library that helps generate
> .doc files.  My reason reason is that such a tool would endorse the
> proprietary format and help continue the dominance of evil proprietary
> formats against standard ones.  The same tool could be just as useful
> writing PDF, DocBook, OpenDocument or even Plain Text instead of any
> version of .doc.  Software engineers should promote standards whenever
> possible, whatever language they use.

+10

-- 
-- Stephe

Re: Generating PDFs with Ada

[sjw]

On Jan 12, 9:00 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On Jan 11, 9:51 am, Stephen Leake <stephen_le...@stephe-leake.org>
> wrote:
>
> > > As long as we're on sort of a similar subject, I've wondered several
> > > times if there are Ada libraries for creating Microsoft Word
> > > documents.
>
> > I hope not :)
>
> Without getting involved into the discussion that follows, I would
> propose everybody to read this:
>
> http://www.joelonsoftware.com/items/2008/02/19.html
>
> The most important part starts with "Let Office do the heavy work for
> you", but the whole article is worth reading.

I especially liked this bit:

"If you really want to generate fancy formatted Word documents, your
best bet is to create an RTF document. Everything that Word can do
can
be expressed in RTF, but it’s a text format, not binary, so you can
change things in the RTF document and it’ll still work. You can
create
a nicely formatted document with placeholders in Word, save as RTF,
and then using simple text substitution, replace the placeholders on
the fly. Now you have an RTF document that every version of Word will
open happily."

Re: Generating PDFs with Ada

[Dmitry A. Kazakov]

On Wed, 12 Jan 2011 01:00:42 -0800 (PST), Maciej Sobczak wrote:

> Some years ago I have been working on the application that was
> supposed to produce Excel documents. I have done it via COM interfaces
> and consider it to be the only reasonable solution for this kind of
> tasks.

You make a valid point from the software design point of view.
Unfortunately Microsoft switches interfaces at the speed only slighter
slower than the formats. Remember DDE, OLE? 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Generating PDFs with Ada

[Manuel Collado]

El 12/01/2011 10:44, sjw escribi�:
> On Jan 12, 9:00 am, Maciej Sobczak<see.my.homep...@gmail.com>  wrote:
>> On Jan 11, 9:51 am, Stephen Leake<stephen_le...@stephe-leake.org>
>> wrote:
>>
>>>> As long as we're on sort of a similar subject, I've wondered several
>>>> times if there are Ada libraries for creating Microsoft Word
>>>> documents.
>>
>>> I hope not :)
>>
>> Without getting involved into the discussion that follows, I would
>> propose everybody to read this:
>>
>> http://www.joelonsoftware.com/items/2008/02/19.html
>>
>> The most important part starts with "Let Office do the heavy work for
>> you", but the whole article is worth reading.
>
> I especially liked this bit:
>
> "If you really want to generate fancy formatted Word documents, your
> best bet is to create an RTF document. Everything that Word can do
> can
> be expressed in RTF, but it�s a text format, not binary, so you can
> change things in the RTF document and it�ll still work. You can
> create
> a nicely formatted document with placeholders in Word, save as RTF,
> and then using simple text substitution, replace the placeholders on
> the fly. Now you have an RTF document that every version of Word will
> open happily."

Another possibility is to use the "Microsoft Office XML formats":

    http://en.wikipedia.org/wiki/Microsoft_Office_XML_formats

Any general-purpose XML tool or library can handle them.

-- 
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado

Re: Generating PDFs with Ada

[Yannick Duchêne (Hibou57)]

Le Wed, 12 Jan 2011 10:36:02 +0100, Pascal Obry <pascal@obry.net> a écrit:
> I paid for Lightroom as there is no equivalent in the Open
> Source domain at the moment [...]
>
> [...]
>
> Let's take Lightroom that I'm using at the moment. The data to develop
> the photos are so tied to Lightroom that I will probably have to keep
> Lightroom forever :( I know but today I have no choice, it is a shame
> but I need to get the job done...

You pointed an interesting point: free as speech is more important as fee  
as beer ;) Most users feel and seek for the opposite, and for those, MS  
Office can be free as beer when it is cracked, and then either OpenOffice  
or MS Office looks the same good alternative, as both are free as beer.

P.S. A quick search on the web to try to help you, gave this:  
http://darktable.sourceforge.net/ I do not like this obsession to clone,  
as found in many software project (just look at the name), but if this  
ever can help you, that's for one good at least...

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Generating PDFs with Ada

[Georg Bauhaus]

On 12.01.11 11:44, Manuel Collado wrote:
> El 12/01/2011 10:44, sjw escribi�:
>> On Jan 12, 9:00 am, Maciej Sobczak<see.my.homep...@gmail.com>  wrote:
>>> On Jan 11, 9:51 am, Stephen Leake<stephen_le...@stephe-leake.org>
>>> wrote:
>>>
>>>>> As long as we're on sort of a similar subject, I've wondered several
>>>>> times if there are Ada libraries for creating Microsoft Word
>>>>> documents.
>>>
>>>> I hope not :)
>>>
>>> Without getting involved into the discussion that follows, I would
>>> propose everybody to read this:
>>>
>>> http://www.joelonsoftware.com/items/2008/02/19.html
>>>

> Another possibility is to use the "Microsoft Office XML formats":
> 
>    http://en.wikipedia.org/wiki/Microsoft_Office_XML_formats
> 
> Any general-purpose XML tool or library can handle them.

Handling Office Open XML in full means to tackle a rather
extensive specification.  ISO announces Part 1 of ISO/IEC
29500:2008 Office Open XML File Formats to have 5560 pages.

XML frees us from binary representations and machine
dependence. However, the meaning of elements, attributes,
rules etc. does not fit into a single brain, in a single life.
(See Joel Spolsky's article.)

You can add the argument about size of specification to Dmitry's
remarks about Microsoft's ongoing productivity when it comes
to outputting new, more capable "formats" to everyone.

Yet, the notion of a document is fairly simple one.  Why would the
simple idea have to be complicated by injecting every possible
twist from the history of PC document exchange?

Because the functioning of politics and management is known
by any competent computer software consultant/salesperson/politician.
If you are one, you know how to produce software to be sold to the
target group: Microsoft style.

It's admirable.

Re: Generating PDFs with Ada

[RasikaSrinivasan@gmail.com]

On Jan 8, 8:00 pm, "R. Tyler Croy" <ty...@linux.com> wrote:
> I have a project idea in my head that I'd /like/ to build with Ada rather than
> Python but I can't seem to find a library for generating PDF files with Ada.
>
> Does such a beast exist?
>
> --
> - R. Tyler Croy
> --------------------------------------
>     Code:http://github.com/rtyler

i see that this thread is a couple of days old - still.

i built a binding to libharu - which is pretty comprehensive but not
the latest.

if you like you could go to:

projectlets.sourceforge.net

let me know if it helps. thanks, srini

Re: Generating PDFs with Ada

[Pascal Obry]

Yannick,

> P.S. A quick search on the web to try to help you, gave this:
> http://darktable.sourceforge.net/ I do not like this obsession to clone,
> as found in many software project (just look at the name), but if this
> ever can help you, that's for one good at least...

Thanks for the link. I indeed build darktable daily from master branch.
But I can tell you that it is far from Lightroom in terms of usability
and most important in terms of noise reduction. The Ligthroom RAW
demosaicing algorithm is far supperior especially at high ISO. But I
also think that Darktable will be a good challenger at some point... But
this is getting really off-topic.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Generating PDFs with Ada

[Florian Weimer]

* Adam Beneschan:

> As long as we're on sort of a similar subject, I've wondered several
> times if there are Ada libraries for creating Microsoft Word
> documents.

Aren't you supposed to use Microsoft Office and COM for this task?
Wouldn't GNATCOM do the job (if it still exist)?

Re: Generating PDFs with Ada

[Maciej Sobczak]

On Jan 12, 11:04 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> You make a valid point from the software design point of view.
> Unfortunately Microsoft switches interfaces at the speed only slighter
> slower than the formats. Remember DDE, OLE?

Still, if your target is a Word file, this is the most stable option.
More stable than the file format itself. I wouldn't be surprised to
see my old code still working properly.

In any case, we can think about this issue in this way: if our
customer already enjoys paying Microsoft every so often for Office
upgrades, then he might also enjoy paying *us* for repeatedly
rewriting the document generation engine within the system that we
maintain for him. Right? ;-)

--
Maciej Sobczak * http://www.inspirel.com

Re: Generating PDFs with Ada

[Dmitry A. Kazakov]

On Wed, 12 Jan 2011 13:25:42 -0800 (PST), Maciej Sobczak wrote:

> On Jan 12, 11:04�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> You make a valid point from the software design point of view.
>> Unfortunately Microsoft switches interfaces at the speed only slighter
>> slower than the formats. Remember DDE, OLE?
> 
> Still, if your target is a Word file, this is the most stable option.

Some time ago it was DDE.

> More stable than the file format itself. I wouldn't be surprised to
> see my old code still working properly.

Well, it depends. An unrelated example, but for the sake of argument, if
you merely change the compiler from VC2008 to VC2010, your C++ program will
stop working under Windows NT4.0,95,98...2000. Instead investigating
possible reasons why, let us just note this. The moral is anything is
possible and anything is likely.

> In any case, we can think about this issue in this way: if our
> customer already enjoys paying Microsoft every so often for Office
> upgrades, then he might also enjoy paying *us* for repeatedly
> rewriting the document generation engine within the system that we
> maintain for him. Right? ;-)

Not really. Surely we don't write *.doc files, I cannot imagine a customer,
who would request that. But we indeed write *.xls files (or what is the
extension now) on many occasions. Customers don't pay for that. They expect
it working, so it is our expenses in the end. The problem is not that
great, because most of the customers keep on using Windows XP and aren't
affected by the "upgrades." But sooner or later the next turn will come.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Generating PDFs with Ada

[Randy Brukardt]

"Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message 
news:87lj2rgkaz.fsf@ludovic-brenta.org...
...
>> And I'm sure there are other tools out there (besides MS Office) that
>> generate .doc files.
>
> Apart from Microsoft's own, I can't think of any such tool.  Then again,
> I don't use office software much, I don't use Windows, and I would
> certainly not use, much less buy, a tool that locks my data into a
> proprietary format like .doc.  Maybe that's because I'm a software
> engineer and not a lemming :)

You're not trying very hard. :-)
OpenOffice produces .doc files. I think most of the web-based "office 
suites" also do. All for pragmatic reasons.

I've tried to take the attitude you are espousing and it has proven 
completely impractical. I've tried distributing documents in .odf format 
(the supposedly open format of OpenOffice) and hardly anyone seemed to be 
happy. It's a lot easier to distribute in .doc format (although I try to 
distribute read-only documents as .PDF).

...
>> It may be that the need for writing a Word document is small enough
>> that nobody has considered it worth their while to write a library
>> like that.  I can accept that as a reason.  But the attitude that I
>> thought I detected---"I hope [that nobody writes a library like
>> that]"---is not one that I believe serves the Ada community.  I
>> apologize if I read too much into anything anyone said.
>
> Like Stephe, I too hope that nobody writes a library that helps generate
> .doc files.  My reason reason is that such a tool would endorse the
> proprietary format and help continue the dominance of evil proprietary
> formats against standard ones.  The same tool could be just as useful
> writing PDF, DocBook, OpenDocument or even Plain Text instead of any
> version of .doc.  Software engineers should promote standards whenever
> possible, whatever language they use.

I think the "library" should be able to generate any kind of file that you 
want. The ARM_Formatter uses an O-O design which allows plugging in any kind 
of output that you might dream up. So long as the clients write to that 
interface (and there is no alternative!), any sort of output can be made.

Personally, I wouldn't want to try to directly create PDF files, because 
that would require doing detailed character layout, justification, 
pagination, indexing, table of contents, and the like. Doing these properly 
is a very complex job (I have experience with writing programs to output via 
typesetters back when I was much younger, and this is very difficult to get 
right). That's why I use MS Word and/or OpenOffice as an intermediary for 
creating the Ada standard and lots of other documents. If I was starting 
that today I would write directly to the .ODF format and let OpenOffice do 
all of the work (but that wasn't an option in 1998).

                                             Randy.

Re: Generating PDFs with Ada

[Randy Brukardt]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:a646191e-6671-4c3a-ab9a-ba20d4bba9bf@r29g2000yqj.googlegroups.com...
>On Jan 11, 9:51 am, Stephen Leake <stephen_le...@stephe-leake.org> wrote:
>
>> > As long as we're on sort of a similar subject, I've wondered several
>> > times if there are Ada libraries for creating Microsoft Word
>> > documents.
>>
>> I hope not :)
>
>Without getting involved into the discussion that follows, I would
>propose everybody to read this:
>
>http://www.joelonsoftware.com/items/2008/02/19.html
>
>The most important part starts with "Let Office do the heavy work for
>you", but the whole article is worth reading.

It's nice to see that his conclusion is the same as mine. I find the 
suggestion to use .rtf more compelling than "let Office do the work for you" 
simply because not everyone has Office installed. (I don't on my newer 
computers, for example.)

It would be useful to note that .rtf files are less stable than .doc files. 
We continued to have bizarre formatting problems with the Ada standard until 
someone noticed that they went away if we took the .rtf files and resaved 
them as .doc files. Moreover, an attempt to save the files as .rtf crashes 
Word (all versions that I've tried). But even with those problems, it's a 
whole lot easier to write .rtf and generate .pdf from that than to try to do 
it in one step.

Moreover, that allows the input to the formatter to be plain text, with all 
of the version control advantages that entails. (And version control is very 
important for a large, long-lived document like the Ada standard.) And it 
allows the creation of multiple related documents (RM and AARM) from a 
single source base. And we can also automatically create some of the annexes 
from the source (like the attribute, pragma, and syntax annexes).

                                    Randy.

Re: Generating PDFs with Ada

[Ludovic Brenta]

Randy Brukardt wrote on comp.lang.ada:
> "Ludovic Brenta" <ludo...@ludovic-brenta.org> wrote in message
>
> news:87lj2rgkaz.fsf@ludovic-brenta.org...
> ...
>
>>> And I'm sure there are other tools out there (besides MS Office) that
>>> generate .doc files.
>
>> Apart from Microsoft's own, I can't think of any such tool.  Then again,
>> I don't use office software much, I don't use Windows, and I would
>> certainly not use, much less buy, a tool that locks my data into a
>> proprietary format like .doc.  Maybe that's because I'm a software
>> engineer and not a lemming :)
>
> You're not trying very hard. :-)
> OpenOffice produces .doc files. I think most of the web-based "office
> suites" also do. All for pragmatic reasons.

OK.  The reason I forgot about them is because I was thinking of
automated document generation, but your point is valid.

> I've tried to take the attitude you are espousing and it has proven
> completely impractical. I've tried distributing documents in .odf format
> (the supposedly open format of OpenOffice) and hardly anyone seemed to be
> happy. It's a lot easier to distribute in .doc format (although I try to
> distribute read-only documents as .PDF).

Yes, in my experience .PDF is the way to go. I generally *don't* want
people to change the documents I send them anyway.

> I think the "library" should be able to generate any kind of file that you
> want. The ARM_Formatter uses an O-O design which allows plugging in any kind
> of output that you might dream up. So long as the clients write to that
> interface (and there is no alternative!), any sort of output can be made.

Again, this argument is technically valid.  But if you're going to
generate documents, it is better to generate them in a standard format
over a non-standard one.

> Personally, I wouldn't want to try to directly create PDF files, because
> that would require doing detailed character layout, justification,
> pagination, indexing, table of contents, and the like. Doing these properly
> is a very complex job (I have experience with writing programs to output via
> typesetters back when I was much younger, and this is very difficult to get
> right). That's why I use MS Word and/or OpenOffice as an intermediary for
> creating the Ada standard and lots of other documents. If I was starting
> that today I would write directly to the .ODF format and let OpenOffice do
> all of the work (but that wasn't an option in 1998).

I agree that typesetting is difficult.  That's why I recommend using
typesetting programs to do that job.  Word processors are generally
bad at handling automatically generated input.  My preferred way would
be to generate TeX, LaTeX or DocBook and use the appropriate system do
the typesetting for me.

--
Ludovic Brenta.

Re: Generating PDFs with Ada

[Ludovic Brenta]

Randy Brukardt wrote on comp.lang.ada:
> It would be useful to note that .rtf files are less stable than .doc files.
> We continued to have bizarre formatting problems with the Ada standard until
> someone noticed that they went away if we took the .rtf files and resaved
> them as .doc files. Moreover, an attempt to save the files as .rtf crashes
> Word (all versions that I've tried). But even with those problems, it's a
> whole lot easier to write .rtf and generate .pdf from that than to try to do
> it in one step.
>
> Moreover, that allows the input to the formatter to be plain text, with all
> of the version control advantages that entails. (And version control is very
> important for a large, long-lived document like the Ada standard.) And it
> allows the creation of multiple related documents (RM and AARM) from a
> single source base. And we can also automatically create some of the annexes
> from the source (like the attribute, pragma, and syntax annexes).

I see we're on the same wavelength as regards professional document
management: plain text, version control, separation of style from
content, etc.

Personally I would have chosen Texinfo, TeX, LaTeX or DocBooc instead
of RTF.  These formats are not ISO standards but they are stable and
open.  It is possible that generating HTML and PDF from such sources
was not yet an option in 1998, though.

--
Ludovic Brenta.

Re: Generating PDFs with Ada

[Georg Bauhaus]

On 1/13/11 9:33 AM, Ludovic Brenta wrote:
> Randy Brukardt wrote on comp.lang.ada:
>> It would be useful to note that .rtf files are less stable than .doc files.
>> We continued to have bizarre formatting problems with the Ada standard until
>> someone noticed that they went away if we took the .rtf files and resaved
>> them as .doc files. Moreover, an attempt to save the files as .rtf crashes
>> Word (all versions that I've tried). But even with those problems, it's a
>> whole lot easier to write .rtf and generate .pdf from that than to try to do
>> it in one step.

> Personally I would have chosen Texinfo, TeX, LaTeX or DocBooc instead
> of RTF.  These formats are not ISO standards but they are stable and
> open.  It is possible that generating HTML and PDF from such sources
> was not yet an option in 1998, though.

DITA  (Darwin Information Typing Architecture) is worth mentioning.
It is unlike the book centric macros, and unlike DocBook.
DITA, offering a very simple set of element definitions (XML), is built
around the notions of a topic, how to connect topics, and how to
specialize a general topic (concepts, how-tos, step-by-step
instructions, ...).
I have never needed to specialize what is already there, though.

"The point of the XML-based Darwin Information Typing Architecture (DITA)
  is to create modular technical documents that are easy to reuse with
  varied display and delivery mechanisms, such as helpsets, manuals,
  hierarchical summaries for small-screen devices, and so on."

   (From "Specializing topic types in DITA",
http://www.ibm.com/developerworks/xml/library/x-dita2/ )

Editing software can output to all kinds of files, including .odt.

Re: Generating PDFs with Ada

[Randy Brukardt]

"Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message 
news:9c34f2cf-cb2c-4433-a6f7-b4c19d842fee@t35g2000yqj.googlegroups.com...
> Randy Brukardt wrote on comp.lang.ada:
>> It would be useful to note that .rtf files are less stable than .doc 
>> files.
>> We continued to have bizarre formatting problems with the Ada standard 
>> until
>> someone noticed that they went away if we took the .rtf files and resaved
>> them as .doc files. Moreover, an attempt to save the files as .rtf 
>> crashes
>> Word (all versions that I've tried). But even with those problems, it's a
>> whole lot easier to write .rtf and generate .pdf from that than to try to 
>> do
>> it in one step.
>>
>> Moreover, that allows the input to the formatter to be plain text, with 
>> all
>> of the version control advantages that entails. (And version control is 
>> very
>> important for a large, long-lived document like the Ada standard.) And it
>> allows the creation of multiple related documents (RM and AARM) from a
>> single source base. And we can also automatically create some of the 
>> annexes
>> from the source (like the attribute, pragma, and syntax annexes).
>
> I see we're on the same wavelength as regards professional document
> management: plain text, version control, separation of style from
> content, etc.
>
> Personally I would have chosen Texinfo, TeX, LaTeX or DocBooc instead
> of RTF.  These formats are not ISO standards but they are stable and
> open.  It is possible that generating HTML and PDF from such sources
> was not yet an option in 1998, though.

In hindsight, I might have as well. But part of the reason that I chose .rtf 
was because that was one of the few formats accepted by ISO for standards. 
.Doc being the other. (Please insert joke here about an International 
Standards Organization requiring documents in a propriatary, non standard 
format. Everyone else has. :-)

Interestingly, the *actual* format that the Ada standards have been 
submitted in has been .PDF. Although ISO recently tried to again insist on 
all documents being in their own closed template for Microsoft Office and in 
.Doc files. Which only works with US versions of Office. What's 
"International" about that?? Anyway, that has again been beaten back - the 
supposed reason that they wanted to do this is so that they could modify the 
standards if they needed to do so. But editors don't want ISO secretaries 
mucking with their standards! What a wonderful way to have a disaster 
(imagine deleting "not" from some text).

                                        Randy.

Re: Generating PDFs with Ada

[Georg Bauhaus]

On 1/13/11 9:40 PM, Randy Brukardt wrote:

> Interestingly, the *actual* format that the Ada standards have been
> submitted in has been .PDF. Although ISO recently tried to again insist on
> all documents being in their own closed template for Microsoft Office and in
> .Doc files. Which only works with US versions of Office. What's
> "International" about that?? Anyway, that has again been beaten back - the
> supposed reason that they wanted to do this is so that they could modify the
> standards if they needed to do so. But editors don't want ISO secretaries
> mucking with their standards! What a wonderful way to have a disaster
> (imagine deleting "not" from some text).

It is interesting to read the stories about ISO delegates  from
northern Europe around the time .doc/OOXML was suggested as an
ISO standard.
Delegates have voted Yes although their national technical committees
had tended to vote No---the committees were then staffed by more
willing members that would understand the advantages of .doc
much  better than the original members ...

The non-technical content of iWoz is illustrative, I think.
It is descriptive of what perhaps explains the special respect
that some Big Silicon Entrepreneurs have for standards organizations.

Re: Generating PDFs with Ada

[Edward Fish]

On Jan 13, 1:40 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
> But editors don't want ISO secretaries
> mucking with their standards! What a wonderful way to have a disaster
> (imagine deleting "not" from some text).
>
>                                         Randy.

Howabout something like replacing the terminal 'and' in a list with
'or' so that said list fits on one line?

Re: Generating PDFs with Ada

[Thomas Løcke]

On 2011-01-13 23:34, Georg Bauhaus wrote:
> It is interesting to read the stories about ISO delegates from
> northern Europe around the time .doc/OOXML was suggested as an
> ISO standard.
> Delegates have voted Yes although their national technical committees
> had tended to vote No---the committees were then staffed by more
> willing members that would understand the advantages of .doc
> much better than the original members ...


Coming from Denmark, this was a _very_ embarrassing process to bear
witness to.

It flies in the face of this study:

http://www.transparency.org/policy_research/surveys_indices/cpi/2010/results

Denmark is a Microsoft haven. For some odd reason(s) that one company
have a very strong influence on the danish politicians/decision makers.

-- 
Regards,
Thomas Løcke

Email: tl at ada-dk.org
Web: http://ada-dk.org
http://identi.ca/thomaslocke

Re: Generating PDFs with Ada

[Elias Salomão Helou Neto]

On Jan 10, 1:48 am, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Mon, 10 Jan 2011 03:29:00 +0100, Stephen Leake  
> <stephen_le...@stephe-leake.org> a écrit:> I considered that path once for building better PDF versions of the Ada
> > language reference manual. I concluded it was not any easier than
> > generating the PDF in the first place.
>
> > I suppose it depends on how complex your document is.
>
> Also I feel LaTeX and its typical utilities are not that much Unicode  
> ready (although Unicode is already 20 years old exactly this year).  

This is not true, simply use

\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}

at the preamble and you're ready to go Unicode.

There are also great tools for generating vector graphics (take a look
at the Tikz/PGF pacakage).

> Writing PDF at the first place is better for that reason at least.

As pointed out, no. OTOH, going this way would potentially result in
much faster software, but in may cases this is not so relevant.

Elias.

Re: Generating PDFs with Ada

[Pascal Obry]

Le 15/01/2011 14:55, Elias Salom�o Helou Neto a �crit :
> This is not true, simply use
> 
> \usepackage[utf8]{inputenc}
> \usepackage[T1]{fontenc}

Right, I'm using this since long time, working just fine.

> There are also great tools for generating vector graphics (take a look
> at the Tikz/PGF pacakage).

Agreed too, I've discovered this package last year, it is a must for sure!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Generating PDFs with Ada

[Elias Salomão Helou Neto]

> Interestingly, the *actual* format that the Ada standards have been
> submitted in has been .PDF. Although ISO recently tried to again insist on
> all documents being in their own closed template for Microsoft Office and in
> .Doc files. Which only works with US versions of Office. What's
> "International" about that?? Anyway, that has again been beaten back - the
> supposed reason that they wanted to do this is so that they could modify the
> standards if they needed to do so. But editors don't want ISO secretaries
> mucking with their standards! What a wonderful way to have a disaster
> (imagine deleting "not" from some text).

I fail to understand how come public institutions use proprietary
formats for their document exchanges. There should be a law against
it. I get sick whenever I get a .doc file to fill in. If it is
possible I return it to the sender asking for a PDF form instead.

With .tex, changing the formatting of the whole document is a breeze.
And it can be done without even having access to the contents files,
perfect for ISO editors. Creating hyperlinked summaries, indices and
bibliographies is as easy as 1,2,3. Not to mention vector graphics
(can you even consider doing that with, say, .rtf?), math formulas and
so on.

Now, for automatic document generation, both from practical and
technical viewpoints, there is no chance for .rtf/.doc/.odt
against .tex as an intermediate format for generating .pdf. Sorry if
this will sound a little bit harsh, but anyone who would choose one of
the three former against the latter, simply doesn't know what is
doing. Anything that can be done by .rtf/.doc/.odt can be done with
LaTeX, but the opposite is just not true.

If you intend to get to pdf through an intermediate format, tex is
just the way to go.

>"The point of the XML-based Darwin Information Typing Architecture (DITA)
>  is to create modular technical documents that are easy to reuse with
>  varied display and delivery mechanisms, such as helpsets, manuals,
>  hierarchical summaries for small-screen devices, and so on."

I have never heard about DITA before, but I must mention that there is
nothing book-centric about TeX itself, therefore your objection
clearly does not apply here. TeX is about beautiful typesetting and it
is a fully fledged macro language, so you can get about anything you
want from it.

Elias

Re: Generating PDFs with Ada

[Elias Salomão Helou Neto]

> > This is not true, simply use
>
> > \usepackage[utf8]{inputenc}
> > \usepackage[T1]{fontenc}
>
> Right, I'm using this since long time, working just fine.

Have you read the TeXBook? It is even fun to read! And it is
impressive to notice that Knuth had foreseen and gracefully handled
such encoding issues long before they become a mainstream problem in
computation. This reminds me a quotation from Schopenhauer:
"Talent hits a target no one else can hit; Genius hits a target no one
else can see."

Also, the whole language is beautifully designed. Anyone should, if
not read, at least know of the classical books in his/her area and the
TeXbook is surely a major achievement in the field of computation, the
work of a true genius.

Elias.

P.S.: Sorry if I've gone off-topic here, but could not resist.

Re: Generating PDFs with Ada

[Yannick Duchêne (Hibou57)]

Le Sat, 15 Jan 2011 16:04:08 +0100, Elias Salomão Helou Neto  
<eshneto@gmail.com> a écrit:
> Now, for automatic document generation, both from practical and
> technical viewpoints, there is no chance for .rtf/.doc/.odt
> against .tex as an intermediate format for generating .pdf. Sorry if
> this will sound a little bit harsh, but anyone who would choose one of
> the three former against the latter, simply doesn't know what is
> doing.
I understand the advocacy, but you still need a source for the document.  
PDF is not a source, and TeX/LaTeX are neither good for that purpose (no  
more than RTF is), added the already pointed fact of lack of real support  
for Unicode (unless you use the 1GB install of an application I forget the  
name) which is a must-have for many text based work (especially if you  
need multiple languages in the same document, like Arabic + French,  
Japanese + Italian, and so on). This is not readable neither.

Better XML as source than TeX/LaTex there. Some document model exist for  
math notations, and anyway, the nature of XML allow you to write a  
document without even the need for a document model reference (you may  
rely on good tag name and not too much obfuscating attributes).

About MS Office document in administrations, at least in france, PDF is  
every where. I receive e-mail bills in PDF, and all official documents you  
can order on-line on administration's web sites, are PDF (do not know for  
other countries, while pretty sure it's the same in all of the Europe).

About PDF now: I remember when it appears in the 199Xs, this was an ogre,  
consuming too much CPU power and memory. This was best used for printing  
than for on-screen reading (the HD was scrapping and grinding as much as  
you were scrolling your document). Word documents, on the opposite, was  
opening fast and with fluidity. This may explain why MS Word document was  
the first favorite at that time. Later and now, with memory and CPU speed  
increases (I hope 1GHz CPU and 1GB memory is at last enough to open a PDF  
smoothly), PDF become more usable for on-screen reading (this is planned  
to be one of the favorite format for e-Books).


Just to say there are reasons for why things was what they use to be (on  
both parts of the trial).


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Generating PDFs with Ada

[Yannick Duchêne (Hibou57)]

Le Sat, 15 Jan 2011 15:51:39 +0100, Pascal Obry <pascal@obry.net> a écrit:

> Le 15/01/2011 14:55, Elias Salomão Helou Neto a écrit :
>> This is not true, simply use
>>
>> \usepackage[utf8]{inputenc}
>> \usepackage[T1]{fontenc}
>
> Right, I'm using this since long time, working just fine.

What about mixing different text directions in the same text ? What about  
combined form of letter whose shapes change depending on the context ? All  
my attempt here failed (I use to think about TeX for PDF generation too,  
but gave up, and I would not install a too much heavy application on a  
server anyway, especially when no root privilege).

>> There are also great tools for generating vector graphics (take a look
>> at the Tikz/PGF pacakage).
>
> Agreed too, I've discovered this package last year, it is a must for  
> sure!
May be, but XML is more widely supported as a parsable format. And vector  
graphic are typically subject to the kind of access and requests XML  
allows, especially with formal diagrams.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Generating PDFs with Ada

[Georg Bauhaus]

On 1/15/11 6:45 PM, Yannick Duchêne (Hibou57) wrote:

> About PDF now: I remember when it appears in the 199Xs, this was an ogre, consuming too much CPU power and memory. This was best used for printing than for on-screen reading (the HD was scrapping and grinding as much as you were scrolling your document). Word documents, on the opposite, was opening fast and with fluidity. This may explain why MS Word document was the first favorite at that time. Later and now, with memory and CPU speed increases (I hope 1GHz CPU and 1GB memory is at last enough to open a PDF smoothly), PDF become more usable for on-screen reading (this is planned to be one of the favorite format for e-Books).


Somewhere on the quoted line you say that PDF was slow in 199X.
I have seen Display Postscript running nicely on high end PC
hardware of the time.

Re: Generating PDFs with Ada

[Georg Bauhaus]

On 1/15/11 4:04 PM, Elias Salom�o Helou Neto wrote:

> Now, for automatic document generation, both from practical and
> technical viewpoints, there is no chance for .rtf/.doc/.odt
> against .tex as an intermediate format for generating .pdf. Sorry if
> this will sound a little bit harsh, but anyone who would choose one of
> the three former against the latter, simply doesn't know what is
> doing. Anything that can be done by .rtf/.doc/.odt can be done with
> LaTeX, but the opposite is just not true.

 From the *practical* point of view, I can think of many features
available in Microsoft Word or OpenOffice Writer (or FrameMaker
or Ventura Publisher, or Adobe Something) not available in TeX.
That's by design. Nevertheless, The ISO Fortran 2003 draft document is
proof that LaTeX is a possibility for this kind of document.  Some
documents accompanying a SofCheck compiler are produced from Lout input.
So that works, too.   (TeXmacs is a formidable editor for technical
stuff. Interestingly, it doesn't use TeX files for storage.)


> If you intend to get to pdf through an intermediate format, tex is
> just the way to go.
>
>> "The point of the XML-based Darwin Information Typing Architecture (DITA)
>>   is to create modular technical documents that are easy to reuse with
>>   varied display and delivery mechanisms, such as helpsets, manuals,
>>   hierarchical summaries for small-screen devices, and so on."
>
> I have never heard about DITA before, but I must mention that there is
> nothing book-centric about TeX itself,

TeX's primary *objective* was/is to provide everything for math books,
including TAOCP, WEB, or math papers, don't you think?  Its prominent
features: paragraph breaking, page breaking, insertions, and math
mode, should be telling.  Anything a little more fancy is brittle and
takes huge efforts to get going smoothly (again, from a practical
point of view).  DITA OTOH is not at all about formatting,
or paragraphs, or pages.  It is about topics, and structuring.
About just the content.  It is nowhere like TeX.

Around 2000, a paperback of publications of Knuth's appeared.
In one of the entries about the history of TeX he explains how
Guy Steele(?) prodded him to add \if.  Had Knuth objected, then
his original plan to make TeX unconditionally a format for only
describing text on pages could have succeeded. The plan was,
IIRC, to support user friendly computer programs that would
produce TeX files. (And not have ambitious programmers try to be
typographers and to be text processor designers using a minimal
macro system only, and literally.)


> therefore your objection
> clearly does not apply here.

The conclusion that TeX is easily used for all kinds of layout
sounds a bit optimistic.  Also, programmatic text processing
feels anything like simple redefining or \newcommanding macros.
Or satisfyingly interactive, if you aren't a programmer editing
"source text".  BTDT.

Flexibility comes with additions like PSTricks.
Nice, but no longer just TeX, and certainly, well, full of tricks.

The Fortran 2003 ISO draft standard is using TeX at some point, though.
Don't know if ISO Fortran 2003 has been submitted as PDF, but the
draft document sure shows all signs of having been produced from
TeX input. (pdfTeX-1.40.9, LaTeX with hyperref package.)
But that's a book...  hyperref won't give you Eclipse help views
easily, or will it?  Or .info files.


> TeX is about beautiful typesetting and it
> is a fully fledged macro language, so you can get about anything you
> want from it.

Assembly language has its beauty and you can get anything you
want from it.  True, but assembly language is not thefirst
choice for all programmers, whatever the powers are that
directly assembling program give us.

Re: Generating PDFs with Ada

[Yannick Duchêne (Hibou57)]

Le Sun, 16 Jan 2011 02:27:07 +0100, Georg Bauhaus  
<rm-host.bauhaus@maps.futureapps.de> a écrit:
> […]
Interesting to see how document authoring and publishing is a so hot topic  
for Ada novelists.

For any people interested in some specific points of the topic; about  
DITA, DocBook and XML and narrative documents (XML focused for narrative  
representation rather than data) :
http://www.oreillynet.com/xml/blog/2008/05/dita_docbook_and_the_art_of_th.html

That said, about documenting and to come back a bit to an old topic opened  
in this usenet (2009, I believe), I wonder if someone know some standards  
for token based folding (not syntax based) in program source as well as  
standards for linking to external entities, like another part of the  
source providing file name and line number or to any other document; all  
of that embedded in comments (obviously).

We already talked here in this usenet, about some Java world annotation  
conventions in comments which could be worth applied as a standard  
convention in many other places, like Ada source (these conventions are  
already become famous in C, Python, JavaScript and others worlds). But I  
don't believe this could be enough, as this provide nothing dedicated to  
token based folding or links to external entities (the question is in some  
way related to a kind of derivative interpretation of literate  
programming).

If any one know any track, … welcome

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Generating PDFs with Ada

[Elias Salomão Helou Neto]

<eshn...@gmail.com> a écrit:
> > Now, for automatic document generation, both from practical and

> I understand the advocacy, but you still need a source for the document.  PDFis not a source, and TeX/LaTeX are neither good for that purpose (no  
> more than RTF is), added the already pointed fact of lack of real support  
> for Unicode (unless you use the 1GB install of an application I forget the  
> name) which is a must-have for many text based work (especially if you  
> need multiple languages in the same document, like Arabic + French,  
> Japanese + Italian, and so on). This is not readable neither.

You are right. In fact, .rtf is a better source in most cases, since
we can't hope to have a secretary who knows TeX. But I meant that in
the context of an automatic generated intermediate format.

> Better XML as source than TeX/LaTex there. Some document model exist for  

I know very much about TeX and very little about XML. If you know
equally well about both then you may be right. Just wondering if
you're not saying that only because you know XML better than TeX.

> About MS Office document in administrations, at least in france,PDFis  
> every where. I receive e-mail bills inPDF, and all official documents you  
> can order on-line on administration's web sites, arePDF(do not know for  
> other countries, while pretty sure it's the same in all of the Europe).

Congratulations to French people. I'm at Brazil and .doc is
everywhere. I don't care how the document is generated, but how it is
exchanged. Why not convert the stuff into a PDF so that everyone can
read it?

> AboutPDFnow: I remember when it appears in the 199Xs, this was an ogre,  
> consuming too much CPU power and memory. This was best used for printing  
> than for on-screen reading (the HD was scrapping and grinding as much as  
> you were scrolling your document).

This was likely an implementation issue. PDF documents have a
precisely located object table, which contains the position of every
object in the file and the format is page based. When you jump to a
page it does not need to read the hole stuff to render it. It is in
contrast with PostScript, which does require everything to be rendered
from the beginning of the document. Still, by that time, PS renderers
were faster than their PDF counterparts.

Elias.

Re: Generating PDFs with Ada

[Elias Salomão Helou Neto]

> What about mixing different text directions in the same text ?

This one is hard with TeX. Still, there seems to be some recent
advances, I just don't recall the TeX variant that tries to tackle the
issue.

> What about  
> combined form of letter whose shapes change depending on the context ?

Do you mean ligatures? This is perfectly possible. Otherwise, please
explain better what you mean.

> I would not install a too much heavy application on a  
> server anyway, especially when no root privilege).

Well, you can pretty much install only what you need. Furthermore, the
privileges issue is not quite TeX related.

> May be, but XML is more widely supported as a parsable format. And vector

This one is indeed a good point to keep in mind.

> graphic are typically subject to the kind of access and requests XML  
> allows, especially with formal diagrams.

Agreed too. Now you made clear the point that if a doc is to be
modified after generated, XML may be a better choice than .tex because
of its natural "parseability".

OTOH this may not be true even if modifications are required. For
example, I may have lost it, but was there any agreement on how to go
from XML to PDF?

Elias.

Re: Generating PDFs with Ada

[Yannick Duchêne (Hibou57)]

Le Sun, 16 Jan 2011 03:49:09 +0100, Elias Salomão Helou Neto  
<eshneto@gmail.com> a écrit:
> I know very much about TeX and very little about XML. If you know
> equally well about both then you may be right. Just wondering if
> you're not saying that only because you know XML better than TeX.

You could know easily (about XML), as that is rather simple: that's a  
standard serialization format. About document models description, there  
are multiple standards (and may be local standard, like me, I use my own),  
each with a particular strength

I know a bit about TeX and derivative (mainly LaTeX). Sure you know it far  
more than me.

> This was likely an implementation issue. PDF documents have a
> precisely located object table, which contains the position of every
> object in the file and the format is page based. When you jump to a
> page it does not need to read the hole stuff to render it. It is in
> contrast with PostScript, which does require everything to be rendered
> from the beginning of the document. Still, by that time, PS renderers
> were faster than their PDF counterparts.
>
> Elias.
Did not knew that. Thanks for the historical point.

Time to say there is something I miss in PDF: the ability to link to a  
particular part of a document from the outside. HTML and the likes have  
identifiers (which can identify a part of a document) which you can link  
to using URL fragments (you know, the “#any-identifier” at the end of some  
URLs).

As explained in another reply to this thread, I am seeking for a standard  
convention, which could among other things, be used to write in comment  
and interpreted by IDE and editors, to link to others source files or  
related documents. But if you cannot link directly to a particular part of  
a document, that is painful if ever the document is big enough.

Think about the Ada reference, which is a rather big document. From time  
to time, you may see replies in this Usenet, with a link to a section of  
the standard, and many time to a particular point of a section. All these  
links are to HTML version of the reference. You cannot link this way to a  
PDF version of the standard, and that is what is missing to these formats,  
which I believe are better suited for printing than for what we could  
expect in a computer environment.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Generating PDFs with Ada

[Yannick Duchêne (Hibou57)]

Le Sun, 16 Jan 2011 04:13:50 +0100, Elias Salomão Helou Neto  
<eshneto@gmail.com> a écrit:
> This one is hard with TeX. Still, there seems to be some recent
> advances, I just don't recall the TeX variant that tries to tackle the
> issue.
This is the big one which weighted 1GB (ouch). Forget the name too, I mark  
this topic and will e-mail you if ever I get this name back.

> Do you mean ligatures? This is perfectly possible. Otherwise, please
> explain better what you mean.
This is indeed related to ligature and is a kind of ligature, while more  
complex. With some language, the shape of a letter totally change  
depending on its context. The most common example is Arabic. Unicode has  
defined Arabic Presentation Forms for that purpose (Form-A and Form-B).  
You may find it here:
http://www.unicode.org/charts/
in “Middle Eastern Scripts”

Some examples here (one of my own site, french, but you can still look at  
the table at the end of the page):
http://www.les-ziboux.rasama.org/ecriture-arabe-cursive.html


> OTOH this may not be true even if modifications are required. For
> example, I may have lost it, but was there any agreement on how to go
> from XML to PDF?
Yes, there is a common one already mentioned here, which is XSL-FO. Two of  
the most famous way to turn an XML document into another are: XSL (mainly  
for XML -> XML and XML -> HTML) and XSL-FO (mainly for XML -> PDF). XSL is  
for transformation of a markups document into another markups document,  
and XSL-FO is transformation of a markups document into a representation  
on a render device (screen, PDF, etc). This can be compared to what CSS is  
to HTML (a simplified view).

Feel free to e-mail me if you need more details (as I am jobless, I am  
also available for services in this area, if ever you need).


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Generating PDFs with Ada

[Simon Wright]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Better XML as source than TeX/LaTex there. Some document model exist
> for math notations, and anyway, the nature of XML allow you to write a
> document without even the need for a document model reference (you may
> rely on good tag name and not too much obfuscating attributes).

I don't see how you can recommend free-structured XML.

XML (in this context) is, or could be, a way of allocating the content
of a document to its appropriate place in the structure of the document
using in-text markup.

This leads to two questions:

(a) what is the structure of the document?

(b) what markup are you going to use?

Suppose we decide to have books with chapters with paragraphs. Are we
going to say

<book>
  <chapter>
    <paragraph>

or

<livre>
  <chapitre>
    <paragraphe>

???

Someone in this thread asked whether you could expect to find a
secretary who understood [La]TeX. I'm pretty sure it used to be
possible; but I wouldn't have thought that was the answer, instead you'd
expect some front-end document preparation system (Wikipedia are going
this way, I believe, to reduce the fear that inexperienced users feel
when seeing MediaWiki markup for the first time).

Re: Generating PDFs with Ada

[Elias Salomão Helou Neto]

On 15 jan, 23:27, Georg Bauhaus <rm-host.bauh...@maps.futureapps.de>
wrote:
>  From the *practical* point of view, I can think of many features
> available in Microsoft Word or OpenOffice Writer (or FrameMaker
> or Ventura Publisher, or Adobe Something) not available in TeX.

How to generate the file formats required by these softs from Ada?

> That's by design.

Yep. They're not designed as intermediate formats to be generated
programatically.

> Nevertheless, The ISO Fortran 2003 draft document is
> proof that LaTeX is a possibility for this kind of document.

Thank you for pointing out the example, but not automatically
generated.

> Some
> documents accompanying a SofCheck compiler are produced from Lout input.

The same than TeX, but different language paradigm. Furthermore, Lout
is not fully capable to generate PDFs.

> So that works, too.   (TeXmacs is a formidable editor for technical
> stuff. Interestingly, it doesn't use TeX files for storage.)

Probably because of its nearly WYSIWYG nature. It is not suitable for
automatically generating PDFs. You will have to edit the stuff
manually. Should we consider using TeXmacs' own format as
intermediate?

> TeX's primary *objective* was/is to provide everything for math books,

Primary. But it does hit farther targets.

> Anything a little more fancy is brittle and
> takes huge efforts to get going smoothly (again, from a practical
> point of view).

Most things are done already and there are packages for about anything
one needs.

> Flexibility comes with additions like PSTricks.
> Nice, but no longer just TeX, and certainly, well, full of tricks.

It is TeX. There is no need to modify the typesetting software because
of the \special macro.

> But that's a book...  hyperref won't give you Eclipse help views
> easily, or will it?  Or .info files.

Why do you mention it? The OP wanted PDFs! When did .info files or
Eclipse help views come into play?

Let us get things straight here. The OP wanted PDFs, if you're using
PDF, you surely want excellent typesetting. As I see TeX is a great
tool for this job.

Elias

Re: Generating PDFs with Ada

[Dmitry A. Kazakov]

On Sun, 16 Jan 2011 11:59:18 +0000, Simon Wright wrote:

> Suppose we decide to have books with chapters with paragraphs. Are we
> going to say
> 
> <book>
>   <chapter>
>     <paragraph>

Let's not. Documents have no such structure. When imposed on, this
structure makes usage of the documents very difficult. I have to work with
many documents on networking issues, they are mostly in PDF. These are
almost unusable *because* they are 1) in PDF, 2) structured as "books,"
which they are not, and never should have been.

A hierarchy of text segments (chapter, paragraph etc) is a possible view of
the document, of which importance is quite minor and becoming more and more
negligible, because documents are never read sequentially. Document is not
a fiction novel. The structure of pages is also a view, a harmful view,
because pages have nothing to do either with the content or with the
rendering on the display.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Generating PDFs with Ada

[(see below)]

On 16/01/2011 12:57, in article olao885lpaij$.1273idj6ytssc$.dlg@40tude.net,
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

> On Sun, 16 Jan 2011 11:59:18 +0000, Simon Wright wrote:
> 
>> Suppose we decide to have books with chapters with paragraphs. Are we
>> going to say
>> 
>> <book>
>>   <chapter>
>>     <paragraph>
> 
> Let's not. Documents have no such structure. When imposed on, this
> structure makes usage of the documents very difficult. ...

There was a fad in the '70s for program editors that worked on the basis of
a similar structure, but derived from the syntax of the programming
language. I never used any of them for more than half an hour because the
kinds of things one wants to do when doing serious editing of source code
simply do not respect the boundaries of syntactic constructs.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Generating PDFs with Ada

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 16 Jan 2011 11:59:18 +0000, Simon Wright wrote:
>
>> Suppose we decide to have books with chapters with paragraphs. Are we
>> going to say
>> 
>> <book>
>>   <chapter>
>>     <paragraph>
>
> Let's not. Documents have no such structure. When imposed on, this
> structure makes usage of the documents very difficult. I have to work with
> many documents on networking issues, they are mostly in PDF. These are
> almost unusable *because* they are 1) in PDF, 2) structured as "books,"
> which they are not, and never should have been.
>
> A hierarchy of text segments (chapter, paragraph etc) is a possible view of
> the document, of which importance is quite minor and becoming more and more
> negligible, because documents are never read sequentially. Document is not
> a fiction novel. The structure of pages is also a view, a harmful view,
> because pages have nothing to do either with the content or with the
> rendering on the display.

Well, you've lost me there. If you had to write something on networking
issues (I say 'something' because if you're going to chuck out book,
chapter, paragraph etc you might as well go the whole hog and chuck out
document too :) how would you structure it?

Re: Generating PDFs with Ada

[Dmitry A. Kazakov]

On Sun, 16 Jan 2011 14:25:53 +0000, (see below) wrote:

> On 16/01/2011 12:57, in article olao885lpaij$.1273idj6ytssc$.dlg@40tude.net,
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> 
>> On Sun, 16 Jan 2011 11:59:18 +0000, Simon Wright wrote:
>> 
>>> Suppose we decide to have books with chapters with paragraphs. Are we
>>> going to say
>>> 
>>> <book>
>>>   <chapter>
>>>     <paragraph>
>> 
>> Let's not. Documents have no such structure. When imposed on, this
>> structure makes usage of the documents very difficult. ...
> 
> There was a fad in the '70s for program editors that worked on the basis of
> a similar structure, but derived from the syntax of the programming
> language.

I don't care much about the internal representation of the documents. In
particular because I don't think that document should be programmed (TeX
was all wrong idea).

> I never used any of them for more than half an hour because the
> kinds of things one wants to do when doing serious editing of source code
> simply do not respect the boundaries of syntactic constructs.

Yes, I think the point is important. There is another example of this.
Visual X-Tools is the worst ever IDE made, for this reason.

(For those lucky, who never heard about it, X-tools render the source code
in a way that visualize the program control structure. E.g. then-part of an
if-statement on the left and the else-part of the right, a sort of textual
block-diagrams.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Generating PDFs with Ada

[Dmitry A. Kazakov]

On Sun, 16 Jan 2011 15:33:25 +0000, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sun, 16 Jan 2011 11:59:18 +0000, Simon Wright wrote:
>>
>>> Suppose we decide to have books with chapters with paragraphs. Are we
>>> going to say
>>> 
>>> <book>
>>>   <chapter>
>>>     <paragraph>
>>
>> Let's not. Documents have no such structure. When imposed on, this
>> structure makes usage of the documents very difficult. I have to work with
>> many documents on networking issues, they are mostly in PDF. These are
>> almost unusable *because* they are 1) in PDF, 2) structured as "books,"
>> which they are not, and never should have been.
>>
>> A hierarchy of text segments (chapter, paragraph etc) is a possible view of
>> the document, of which importance is quite minor and becoming more and more
>> negligible, because documents are never read sequentially. Document is not
>> a fiction novel. The structure of pages is also a view, a harmful view,
>> because pages have nothing to do either with the content or with the
>> rendering on the display.
> 
> Well, you've lost me there. If you had to write something on networking
> issues (I say 'something' because if you're going to chuck out book,
> chapter, paragraph etc you might as well go the whole hog and chuck out
> document too :) how would you structure it?

It should be an interlinked network of text pieces. Its representation
should depend on the current view, especially the order and the visibility
of its parts. Consider Ada's RM, ARM and the Rationale as one document. It
is impossible to have as a structure of chapters, it just does not work.
Further, text is not the only part of the document. There are links which
should be rendered in the text. They should also be rendered outside the
text as a graph, a cloud diagram, etc. There are bookmarks, history of text
navigation, history of document changes, readers comments etc.

You mentioned Wiki, which obviously is a far better presentation model or
electronic documentation than PDF. So far I saw no satisfactory ideas of
how computer-era documentation should be made.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Generating PDFs with Ada

[Georg Bauhaus]

On 1/16/11 1:27 PM, Elias Salom�o Helou Neto wrote:
> On 15 jan, 23:27, Georg Bauhaus<rm-host.bauh...@maps.futureapps.de>
> wrote:
>>   From the *practical* point of view, I can think of many features
>> available in Microsoft Word or OpenOffice Writer (or FrameMaker
>> or Ventura Publisher, or Adobe Something) not available in TeX.
>
> How to generate the file formats required by these softs from Ada?

(1) Write a program controlling any capable text processing software's
programming interface, as was suggested.  This method will be
forgetful of internal data formats of these programs.  The method is
unavailable if you don't have the programs.  A third party could be
offering a ready made class library for generating the files, though.

(2) Depending on the level of abstraction, one may generate .gen
files or maker files just like LaTeX files.  I find targeting
anything at a level lower than that to be an attempt at reinventing
big wheels.


>> Nevertheless, The ISO Fortran 2003 draft document is
>> proof that LaTeX is a possibility for this kind of document.
>
> Thank you for pointing out the example, but not automatically
> generated.

Really? I don't know how the Fortran people had generated input
for TeX.


>> So that works, too.   (TeXmacs is a formidable editor for technical
>> stuff. Interestingly, it doesn't use TeX files for storage.)
>
> Probably because of its nearly WYSIWYG nature.

Nearly?

> It is not suitable for
> automatically generating PDFs.

Have your Ada program generate a TeXmacs files, in Scheme format.
Then,

$ texmacs --convert test.scm test.pdf --quit

Similar to how one uses LaTeX or Lout.
Is it possible to run Word simply like

C:\MyFiles> word /convert /in:test.docx /out:test.pdf  /quit


> There is no need to modify the typesetting software because
> of the \special macro.

\special is indicating a need for output that TeX alone cannot
produce.  Is this standard enough?


>> But that's a book...  hyperref won't give you Eclipse help views
>> easily, or will it?  Or .info files.
>
> Why do you mention it? The OP wanted PDFs! When did .info files or
> Eclipse help views come into play?

I got carried away, thinking about the document generating processes,
and in particular, about how a document will be used.  (By clients,
programmers, ISO, ...)
If you want typographically flexible typesetting (really, layout),
TeX is out of the question (for example, frames that span a page
break?).  If you wanted to write an Ada program that generates this
in PDF directly, wouldn't you be trying hard to reinvent text
formatting?

Re: Generating PDFs with Ada

[Yannick Duchêne (Hibou57)]

Le Sun, 16 Jan 2011 12:59:18 +0100, Simon Wright <simon@pushface.org> a  
écrit:

> "Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
>
>> Better XML as source than TeX/LaTex there. Some document model exist
>> for math notations, and anyway, the nature of XML allow you to write a
>> document without even the need for a document model reference (you may
>> rely on good tag name and not too much obfuscating attributes).
>
> I don't see how you can recommend free-structured XML.
>
Please, forget about this particular one sentence. I feel I was wrong to  
introduce this one. Using a model is obviously recommended. I just wanted  
to underline the transparency of this kind of source. Further more, I did  
not had large systems in mid when I wrote this (my own fault to not have  
been more precise about it). Apologize.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Generating PDFs with Ada

[Yannick Duchêne (Hibou57)]

Le Sun, 16 Jan 2011 17:43:22 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> Yes, I think the point is important. There is another example of this.
> Visual X-Tools is the worst ever IDE made, for this reason.
>
> (For those lucky, who never heard about it, X-tools render the source  
> code
> in a way that visualize the program control structure. E.g. then-part of  
> an
> if-statement on the left and the else-part of the right, a sort of  
> textual
> block-diagrams.)

This sort of representation could be relevant (think about UML diagrams)  
for some usages. The error is to display the real source in such a way.  
This graphical representation is good for outlines, and to be useful,  
should be able to make a kind of excerpts of the source.

There are also the visual paradigms used for beginners. This work nice,  
that is not so bad, just that only works fine on small things. Otherwise,  
the amount of area required to represent a part of a source being far  
above what is required to represent the same with text, this does not help  
readability (required when things become larger).

May be the kind of product you mentioned targets bad decisioners ? (at  
least people with a bad representation of what the real things are).

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: Generating PDFs with Ada

[Yannick Duchêne (Hibou57)]

Le Sun, 16 Jan 2011 16:33:25 +0100, Simon Wright <simon@pushface.org> a  
écrit:
>> A hierarchy of text segments (chapter, paragraph etc) is a possible  
>> view of
>> the document, of which importance is quite minor and becoming more and  
>> more
>> negligible, because documents are never read sequentially. Document is  
>> not
>> a fiction novel. The structure of pages is also a view, a harmful view,
>> because pages have nothing to do either with the content or with the
>> rendering on the display.
>
> Well, you've lost me there. If you had to write something on networking
> issues (I say 'something' because if you're going to chuck out book,
> chapter, paragraph etc you might as well go the whole hog and chuck out
> document too :) how would you structure it?
Pascal or Ludovic introduced DITA in this topic. May be he would like this  
one ;) This one use multiple part to be later merged together (the merge  
may be done in multiple way, simultaneously), while DocBook create a  
monolithic document the first time.

I suppose what Dmitry was to notice, has more to deal with *premature  
formating*, just like there is premature optmization, than with Book and  
Page used as paradigm to talk about the structure of a document.

What to use depends on the area. Think about a software design, you have  
comments in the source, some documentation fragment on the topic of the  
application and its area. How could you create a single document from this  
? There is no way. You would better consider all of these to be standalone  
document fragments, then do an assemblage of these fragments targeting  
users, another targeting the maintainers, another targeting document used  
to promote the application, and so on.

Obviously, you need something common to these fragment, something which  
make these to know about each other when required and be able to merged  
these together, to know what kind of fragment is this, how it relate to  
other. That is what DITA is for (and RDF may be useful too here).

Now think about some movie review, there is less something like  
independent fragments here, and you may prefer DocBook instead (DITA is  
likely to be useless at all here).

Note 1: DITA may produce DocBook, these are not opposite.
Note 2: I said DITA and DocBook, while this may be any other systems of  
conventions with the same functionalities (as an example, DocBook is known  
to be too much for some applications, the same about DITA).


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]