state of Adobe s Mars PDFXML project

state of Adobe's Mars/PDFXML project?

Hi all,

does anyone here know anything about the current state of Adobe's Mars
project?  As far as I know it was planned to be a built-in feature of
Acrobat (and Adobe Reader?), but it's pretty quiet around the whole
thing, so I fear that Adobe might no longer be working on it.  I find
PDFXML a pretty interesting thing because I would like to create PDF
files from XML sources via XSLT.  (Just in case you wonder why I don't
want to use XSL-FO:  It's mostly about creating graphical objects, not
text.  And the graphical output has to be precisely reproducible by
any XSLT processor.)

Does anyone have any information?  Is there a future for Mars or
should I better turn to plain SVG?

Thomas W.

Re: state of Adobe's Mars/PDFXML project?

ThomasW wrote:
> Hi all,
> 
> does anyone here know anything about the current state of Adobe's Mars
> project?  As far as I know it was planned to be a built-in feature of
> Acrobat (and Adobe Reader?), but it's pretty quiet around the whole
> thing, so I fear that Adobe might no longer be working on it.  I find
> PDFXML a pretty interesting thing because I would like to create PDF
> files from XML sources via XSLT.  (Just in case you wonder why I don't
> want to use XSL-FO:  It's mostly about creating graphical objects, not
> text.  And the graphical output has to be precisely reproducible by
> any XSLT processor.)
> 
> Does anyone have any information?  Is there a future for Mars or
> should I better turn to plain SVG?
> 
> Thomas W.

There is a thread on the adobe developer's forum for
Mars General Discussion
with Topic tile 'Any word on the path forward'

http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?forumid=72&catid=620&threadid=1335044&enterthread=y

One message, from Matt Hardy (09/16/2008), looks particularly relevant 
to you:

Just to follow up on some of these comments. We have just released the 
new version of Mars/PDFXML. This new version is fully compliant with the 
PDF features available in Acrobat 9.

dcpetersen: Not sure if you are still checking these forums, but have 
you considered creating a PDF Portfolio using PDFXML Syntax. That lets 
you embed native file types such as SWF, FLV (Flash Video), Images, 
Sound, etc. directly into a "package" that can then be viewed directly 
from within Adobe Reader (or of course Acrobat 9 Professional). If you 
want an example of how to do this, go to the Mars Adobe Labs Site and 
check out our Samples. We have a new one that shows how to create a 
Portfolio in PDFXML.

Re: state of Adobe's Mars/PDFXML project?

On 1 Feb., 10:57, Ken Starks <stra...@lampsacos.demon.co.uk> wrote:
>
> There is a thread on the adobe developer's forum for
> Mars General Discussion
> with Topic tile 'Any word on the path forward'
>

Yes, thanks, I already read that post from September 16th 2008.  That
seems to be the last official information from Adobe that reached the
public (about Mars, of course).  I just want to make sure that I don't
waste my time on PDFXML in vain.  I sent an e-mail to one of the Mars
contact addresses a week ago, but didn't get a reply (yet).  I should
try once more, though.  It wouldn't be the first time an e-mail got
lost on its way (or devoured by a hungry spam eating monster).

Thomas W.

Re: state of Adobe's Mars/PDFXML project?

ThomasW wrote:
> On 1 Feb., 10:57, Ken Starks <stra...@lampsacos.demon.co.uk> wrote:
>> There is a thread on the adobe developer's forum for
>> Mars General Discussion
>> with Topic tile 'Any word on the path forward'
>>
> 
> Yes, thanks, I already read that post from September 16th 2008.  That
> seems to be the last official information from Adobe that reached the
> public (about Mars, of course).  I just want to make sure that I don't
> waste my time on PDFXML in vain.  I sent an e-mail to one of the Mars
> contact addresses a week ago, but didn't get a reply (yet).  I should
> try once more, though.  It wouldn't be the first time an e-mail got
> lost on its way (or devoured by a hungry spam eating monster).
> 
> Thomas W.

I didn't refer to that post because I recommend PDFXML, I don't.

Building up your skills at SVG is likely to be a much better
investment of your time and effort.

But post-production conversion from SVG to PDF is not entirely
trouble-free, if you use open-source software. (Layers,
Transparency, font inclusion/substitution, shading and pattern 
dictionaries, ... there is more to it than you might think. )
The Apache Batik project is the most advanced, to my knowledge.
Adobe still seem to want you to buy Illustrator and convert to
PDF from there, greedy people (IMHO).

Even on the commercial side, XSL-FO processors don't always
do full credit to SVG graphics without an extra-cost optional
add-on.

As you considered the PDFXML route, I presume you prefer to generate
your graphics from another data-source rather than an interactive
application such as inkscape or Adobe Illustrator.

XSLT is just one possibility. As Peter has suggested, you might also
consider a LaTeX-based work-flow, such as pgf-tikz, PS-tricks, or PyX.

It seems to me that Adobe are throwing much of their XML energy into
Flex 2, their 'kind-of', 'not-quite' open way for us all to generate 
Flash-based stuff by writing to an XML format.

My conclusion is that, keeping content separate from presentation, you 
need an common format for your data-source that is capable---at least
in principal---of auto-conversion to each of the above outputs.

My own main current project is in mapping. The main output formats are
.kml (Google Earth) and .svg, but I am keeping half-an-eye on pgf/tikz
as a future possibility.

Bye for now,
Ken.

Re: state of Adobe's Mars/PDFXML project?

On 2 Feb., 16:52, Ken Starks <stra...@lampsacos.demon.co.uk> wrote:
>
> But post-production conversion from SVG to PDF is not entirely
> trouble-free, if you use open-source software. (Layers,
> Transparency, font inclusion/substitution, shading and pattern
> dictionaries, ... there is more to it than you might think. )

That's exactly the problem that PDFXML would solve:  Essentially, it's
an SVG dialect that is designed to be 100% compatible with PDF, i.e.
conversion back and forth between traditional PDF and PDFXML is
possible without loss of information.  (If Mars dies, the SVG pages
inside the PDFXML zip archive should still be readable by usual SVG
apps if I can avoid PDF-specific SVG extensions.)

> The Apache Batik project is the most advanced, to my knowledge.
>

Yes, I'll probably use Batik for rendering.

> As you considered the PDFXML route, I presume you prefer to generate
> your graphics from another data-source rather than an interactive
> application such as inkscape or Adobe Illustrator.
>

Actually I'd want to create a special purpose interactive application
myself.

> XSLT is just one possibility. As Peter has suggested, you might also
> consider a LaTeX-based work-flow, such as pgf-tikz, PS-tricks, or PyX.
>

I hardly know anything about those, but I don't think they would allow
me to manipulate some elements of the source data and update the
corresponding graphical elements, would they?  With XML and SVG that
shouldn't be too difficult, I think.

>
> My conclusion is that, keeping content separate from presentation, you
> need an common format for your data-source that is capable---at least
> in principal---of auto-conversion to each of the above outputs.
>

Separation of content and presentation is not my goal, on the
contrary.  I want to precisely describe pages, but instead of
graphical primitives I want to store an XML representation of more or
less complex compound graphical objects.  Those XML representations
would have to be transformed into graphical primitives in form of SVG
nodes.

Thomas W.

Re: state of Adobe's Mars/PDFXML project?

I'm a bit too busy today to give a detailed response, but here's a quick 
one.

1. It looks to me as if you are at least three-quarters of the
way towards 'separation of content from presentation'

2. In principal, the LaTeX family of solutions can respond
automatically to a change in your source data (i.e whatever ?XML?
format your application uses internally). But it would require
a one-way pipeline stage from xMl to their own markup.

Likely to be a bit slow for interactive use; more likely a
refresh/makefile/whatever from time to time.

pdfTeX provides low-level access to to PDF format at an
object-by-object level. Heiko Oberdiek seems to be the main
man here

3. pgfTikz might be getting an SVG import filter. Google for Kjell
Magne Fauske's site. He is the main man here, i think.

4. With PxX you get the whole of python behind you. But it hasn't
got patterned fills (yet) - one of my on-the-back-boiler
projects.



ThomasW wrote:
> On 2 Feb., 16:52, Ken Starks <stra...@lampsacos.demon.co.uk> wrote:
>> But post-production conversion from SVG to PDF is not entirely
>> trouble-free, if you use open-source software. (Layers,
>> Transparency, font inclusion/substitution, shading and pattern
>> dictionaries, ... there is more to it than you might think. )
> 
> That's exactly the problem that PDFXML would solve:  Essentially, it's
> an SVG dialect that is designed to be 100% compatible with PDF, i.e.
> conversion back and forth between traditional PDF and PDFXML is
> possible without loss of information.  (If Mars dies, the SVG pages
> inside the PDFXML zip archive should still be readable by usual SVG
> apps if I can avoid PDF-specific SVG extensions.)
> 
>> The Apache Batik project is the most advanced, to my knowledge.
>>
> 
> Yes, I'll probably use Batik for rendering.
> 
>> As you considered the PDFXML route, I presume you prefer to generate
>> your graphics from another data-source rather than an interactive
>> application such as inkscape or Adobe Illustrator.
>>
> 
> Actually I'd want to create a special purpose interactive application
> myself.
> 
>> XSLT is just one possibility. As Peter has suggested, you might also
>> consider a LaTeX-based work-flow, such as pgf-tikz, PS-tricks, or PyX.
>>
> 
> I hardly know anything about those, but I don't think they would allow
> me to manipulate some elements of the source data and update the
> corresponding graphical elements, would they?  With XML and SVG that
> shouldn't be too difficult, I think.
> 
>> My conclusion is that, keeping content separate from presentation, you
>> need an common format for your data-source that is capable---at least
>> in principal---of auto-conversion to each of the above outputs.
>>
> 
> Separation of content and presentation is not my goal, on the
> contrary.  I want to precisely describe pages, but instead of
> graphical primitives I want to store an XML representation of more or
> less complex compound graphical objects.  Those XML representations
> would have to be transformed into graphical primitives in form of SVG
> nodes.
> 
> Thomas W.

Re: state of Adobe's Mars/PDFXML project?

ThomasW wrote:
> Hi all,
> 
> does anyone here know anything about the current state of Adobe's Mars
> project?  As far as I know it was planned to be a built-in feature of
> Acrobat (and Adobe Reader?), but it's pretty quiet around the whole
> thing, so I fear that Adobe might no longer be working on it.  

I suspect it has quietly died a death.

> I find PDFXML a pretty interesting thing because I would like to
> create PDF files from XML sources via XSLT. (Just in case you wonder
> why I don't want to use XSL-FO: It's mostly about creating graphical
> objects, not text. And the graphical output has to be precisely
> reproducible by any XSLT processor.)

SVG or LaTeX/PDFtricks/TiKZ

> Does anyone have any information?  Is there a future for Mars or
> should I better turn to plain SVG?

SVG would possibly require more work than LaTeX, as the LaTeX graphics 
packages are now really quite extensive.

///Peter

Re: state of Adobe's Mars/PDFXML project?

On 1 Feb., 13:29, Peter Flynn <peter.n...@m.silmaril.ie> wrote:
> ThomasW wrote:
> > It's mostly about creating graphical
> > objects, not text. And the graphical output has to be precisely
> > reproducible by any XSLT processor.)
>
> SVG or LaTeX/PDFtricks/TiKZ
>
> > Does anyone have any information? =A0Is there a future for Mars or
> > should I better turn to plain SVG?
>
> SVG would possibly require more work than LaTeX, as the LaTeX graphics
> packages are now really quite extensive.
>

Peter, thanks for you advice.  It tells me once more that I really
should learn LaTeX (I was about to do so more than once, but - oh
well...).  However, I'm pretty sure that SVG, either with Mars or
without it, is the right thing for the purpose.  The source XML will
already be pretty graphical in nature, only on a more semantic level.
It will closely correspond with the to be created SVG tree.

Thomas W.

Re: state of Adobe's Mars/PDFXML project?

ThomasW wrote:
> Peter, thanks for you advice.  It tells me once more that I really
> should learn LaTeX (I was about to do so more than once, but - oh
> well...).  

http://latex.silmaril.ie/ is a good introduction (mine, so I'm biased), 
and it lists lots of other online sources. It also needs updating... 
<sigh/> when I get a little more time...

> However, I'm pretty sure that SVG, either with Mars or without it, is
> the right thing for the purpose.  The source XML will already be
> pretty graphical in nature, only on a more semantic level. It will
> closely correspond with the to be created SVG tree.

Definitely use SVG for creating graphical objects. But if you create PDF 
objects from them, they can easily be embedded in any document using 
LaTeX (and lots of other systems too). As with most of these things, use 
XML for the master version; create something else from it when needed.

///Peter

Re: state of Adobe's Mars/PDFXML project?

On 1 Feb., 13:29, Peter Flynn <peter.n...@m.silmaril.ie> wrote:
> ThomasW wrote:
> > It's mostly about creating graphical
> > objects, not text. And the graphical output has to be precisely
> > reproducible by any XSLT processor.)
>
> SVG or LaTeX/PDFtricks/TiKZ
>
> > Does anyone have any information? =A0Is there a future for Mars or
> > should I better turn to plain SVG?
>
> SVG would possibly require more work than LaTeX, as the LaTeX graphics
> packages are now really quite extensive.
>

Peter, thanks for you advice.  It tells me once more that I really
should learn LaTeX (I was about to do so more than once, but - oh
well...).  However, I'm pretty sure that SVG, either with Mars or
without it, is the right thing for the purpose.  The source XML will
already be pretty graphical in nature, only on a more semantic level.
It will closely correspond with the to be created SVG tree.

Thomas W.

state of Adobe's Mars/PDFXML project?

Hi all,

does anyone here know anything about the current state of Adobe's Mars
project?  As far as I know it was planned to be a built-in feature of
Acrobat (and Adobe Reader?), but it's pretty quiet around the whole
thing, so I fear that Adobe might no longer be working on it.  I find
PDFXML a pretty interesting thing because I would like to create PDF
files from XML sources via XSLT.  (Just in case you wonder why I don't
want to use XSL-FO:  It's mostly about creating graphical objects, not
text.  And the graphical output has to be precisely reproducible by
any XSLT processor.)

Does anyone have any information?  Is there a future for Mars or
should I better turn to plain SVG?

Thomas W.

Re: state of Adobe's Mars/PDFXML project?

ThomasW wrote:
> Hi all,
> 
> does anyone here know anything about the current state of Adobe's Mars
> project?  As far as I know it was planned to be a built-in feature of
> Acrobat (and Adobe Reader?), but it's pretty quiet around the whole
> thing, so I fear that Adobe might no longer be working on it.  I find
> PDFXML a pretty interesting thing because I would like to create PDF
> files from XML sources via XSLT.  (Just in case you wonder why I don't
> want to use XSL-FO:  It's mostly about creating graphical objects, not
> text.  And the graphical output has to be precisely reproducible by
> any XSLT processor.)
> 
> Does anyone have any information?  Is there a future for Mars or
> should I better turn to plain SVG?
> 
> Thomas W.

There is a thread on the adobe developer's forum for
Mars General Discussion
with Topic tile 'Any word on the path forward'

http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?forumid=72&catid=620&threadid=1335044&enterthread=y

One message, from Matt Hardy (09/16/2008), looks particularly relevant 
to you:

Just to follow up on some of these comments. We have just released the 
new version of Mars/PDFXML. This new version is fully compliant with the 
PDF features available in Acrobat 9.

dcpetersen: Not sure if you are still checking these forums, but have 
you considered creating a PDF Portfolio using PDFXML Syntax. That lets 
you embed native file types such as SWF, FLV (Flash Video), Images, 
Sound, etc. directly into a "package" that can then be viewed directly 
from within Adobe Reader (or of course Acrobat 9 Professional). If you 
want an example of how to do this, go to the Mars Adobe Labs Site and 
check out our Samples. We have a new one that shows how to create a 
Portfolio in PDFXML.

Re: state of Adobe's Mars/PDFXML project?

On 1 Feb., 10:57, Ken Starks <stra...@lampsacos.demon.co.uk> wrote:
>
> There is a thread on the adobe developer's forum for
> Mars General Discussion
> with Topic tile 'Any word on the path forward'
>

Yes, thanks, I already read that post from September 16th 2008.  That
seems to be the last official information from Adobe that reached the
public (about Mars, of course).  I just want to make sure that I don't
waste my time on PDFXML in vain.  I sent an e-mail to one of the Mars
contact addresses a week ago, but didn't get a reply (yet).  I should
try once more, though.  It wouldn't be the first time an e-mail got
lost on its way (or devoured by a hungry spam eating monster).

Thomas W.

Re: state of Adobe's Mars/PDFXML project?

ThomasW wrote:
> On 1 Feb., 10:57, Ken Starks <stra...@lampsacos.demon.co.uk> wrote:
>> There is a thread on the adobe developer's forum for
>> Mars General Discussion
>> with Topic tile 'Any word on the path forward'
>>
> 
> Yes, thanks, I already read that post from September 16th 2008.  That
> seems to be the last official information from Adobe that reached the
> public (about Mars, of course).  I just want to make sure that I don't
> waste my time on PDFXML in vain.  I sent an e-mail to one of the Mars
> contact addresses a week ago, but didn't get a reply (yet).  I should
> try once more, though.  It wouldn't be the first time an e-mail got
> lost on its way (or devoured by a hungry spam eating monster).
> 
> Thomas W.

I didn't refer to that post because I recommend PDFXML, I don't.

Building up your skills at SVG is likely to be a much better
investment of your time and effort.

But post-production conversion from SVG to PDF is not entirely
trouble-free, if you use open-source software. (Layers,
Transparency, font inclusion/substitution, shading and pattern 
dictionaries, ... there is more to it than you might think. )
The Apache Batik project is the most advanced, to my knowledge.
Adobe still seem to want you to buy Illustrator and convert to
PDF from there, greedy people (IMHO).

Even on the commercial side, XSL-FO processors don't always
do full credit to SVG graphics without an extra-cost optional
add-on.

As you considered the PDFXML route, I presume you prefer to generate
your graphics from another data-source rather than an interactive
application such as inkscape or Adobe Illustrator.

XSLT is just one possibility. As Peter has suggested, you might also
consider a LaTeX-based work-flow, such as pgf-tikz, PS-tricks, or PyX.

It seems to me that Adobe are throwing much of their XML energy into
Flex 2, their 'kind-of', 'not-quite' open way for us all to generate 
Flash-based stuff by writing to an XML format.

My conclusion is that, keeping content separate from presentation, you 
need an common format for your data-source that is capable---at least
in principal---of auto-conversion to each of the above outputs.

My own main current project is in mapping. The main output formats are
.kml (Google Earth) and .svg, but I am keeping half-an-eye on pgf/tikz
as a future possibility.

Bye for now,
Ken.

Re: state of Adobe's Mars/PDFXML project?

On 2 Feb., 16:52, Ken Starks <stra...@lampsacos.demon.co.uk> wrote:
>
> But post-production conversion from SVG to PDF is not entirely
> trouble-free, if you use open-source software. (Layers,
> Transparency, font inclusion/substitution, shading and pattern
> dictionaries, ... there is more to it than you might think. )

That's exactly the problem that PDFXML would solve:  Essentially, it's
an SVG dialect that is designed to be 100% compatible with PDF, i.e.
conversion back and forth between traditional PDF and PDFXML is
possible without loss of information.  (If Mars dies, the SVG pages
inside the PDFXML zip archive should still be readable by usual SVG
apps if I can avoid PDF-specific SVG extensions.)

> The Apache Batik project is the most advanced, to my knowledge.
>

Yes, I'll probably use Batik for rendering.

> As you considered the PDFXML route, I presume you prefer to generate
> your graphics from another data-source rather than an interactive
> application such as inkscape or Adobe Illustrator.
>

Actually I'd want to create a special purpose interactive application
myself.

> XSLT is just one possibility. As Peter has suggested, you might also
> consider a LaTeX-based work-flow, such as pgf-tikz, PS-tricks, or PyX.
>

I hardly know anything about those, but I don't think they would allow
me to manipulate some elements of the source data and update the
corresponding graphical elements, would they?  With XML and SVG that
shouldn't be too difficult, I think.

>
> My conclusion is that, keeping content separate from presentation, you
> need an common format for your data-source that is capable---at least
> in principal---of auto-conversion to each of the above outputs.
>

Separation of content and presentation is not my goal, on the
contrary.  I want to precisely describe pages, but instead of
graphical primitives I want to store an XML representation of more or
less complex compound graphical objects.  Those XML representations
would have to be transformed into graphical primitives in form of SVG
nodes.

Thomas W.

Re: state of Adobe's Mars/PDFXML project?

I'm a bit too busy today to give a detailed response, but here's a quick 
one.

1. It looks to me as if you are at least three-quarters of the
way towards 'separation of content from presentation'

2. In principal, the LaTeX family of solutions can respond
automatically to a change in your source data (i.e whatever ?XML?
format your application uses internally). But it would require
a one-way pipeline stage from xMl to their own markup.

Likely to be a bit slow for interactive use; more likely a
refresh/makefile/whatever from time to time.

pdfTeX provides low-level access to to PDF format at an
object-by-object level. Heiko Oberdiek seems to be the main
man here

3. pgfTikz might be getting an SVG import filter. Google for Kjell
Magne Fauske's site. He is the main man here, i think.

4. With PxX you get the whole of python behind you. But it hasn't
got patterned fills (yet) - one of my on-the-back-boiler
projects.



ThomasW wrote:
> On 2 Feb., 16:52, Ken Starks <stra...@lampsacos.demon.co.uk> wrote:
>> But post-production conversion from SVG to PDF is not entirely
>> trouble-free, if you use open-source software. (Layers,
>> Transparency, font inclusion/substitution, shading and pattern
>> dictionaries, ... there is more to it than you might think. )
> 
> That's exactly the problem that PDFXML would solve:  Essentially, it's
> an SVG dialect that is designed to be 100% compatible with PDF, i.e.
> conversion back and forth between traditional PDF and PDFXML is
> possible without loss of information.  (If Mars dies, the SVG pages
> inside the PDFXML zip archive should still be readable by usual SVG
> apps if I can avoid PDF-specific SVG extensions.)
> 
>> The Apache Batik project is the most advanced, to my knowledge.
>>
> 
> Yes, I'll probably use Batik for rendering.
> 
>> As you considered the PDFXML route, I presume you prefer to generate
>> your graphics from another data-source rather than an interactive
>> application such as inkscape or Adobe Illustrator.
>>
> 
> Actually I'd want to create a special purpose interactive application
> myself.
> 
>> XSLT is just one possibility. As Peter has suggested, you might also
>> consider a LaTeX-based work-flow, such as pgf-tikz, PS-tricks, or PyX.
>>
> 
> I hardly know anything about those, but I don't think they would allow
> me to manipulate some elements of the source data and update the
> corresponding graphical elements, would they?  With XML and SVG that
> shouldn't be too difficult, I think.
> 
>> My conclusion is that, keeping content separate from presentation, you
>> need an common format for your data-source that is capable---at least
>> in principal---of auto-conversion to each of the above outputs.
>>
> 
> Separation of content and presentation is not my goal, on the
> contrary.  I want to precisely describe pages, but instead of
> graphical primitives I want to store an XML representation of more or
> less complex compound graphical objects.  Those XML representations
> would have to be transformed into graphical primitives in form of SVG
> nodes.
> 
> Thomas W.

Re: state of Adobe's Mars/PDFXML project?

On 3 Feb., 11:31, Ken Starks <stra...@lampsacos.demon.co.uk> wrote:
> I'm a bit too busy today to give a detailed response, but here's a quick
> one.
>

Your help is really kind.

>
> 2. In principal, the LaTeX family of solutions can respond
> automatically to a change in your source data (i.e whatever ?XML?
> format your application uses internally). But it would require
> a one-way pipeline stage from xMl to their own markup.
>
> Likely to be a bit slow for interactive use; more likely a
> refresh/makefile/whatever from time to time.
>

That's crucial.  Things like mouse dragging will have to be supported
with decent redraw rates.  It appears to me that SVG is excellently
suited for that purpose because one could make use of its built in
interaction event handling features and redrawing capabilities.  My
impression is that a LaTeX/PDF approach would be much less convenient
(and too slow, as you pointed out).

For the PDF conversion part, I think I'll restrict myself to a subset
of SVG that can be be converted to PDF without trouble.  I probably
won't need transparency, gradients, layers and that kind of stuff.

Thomas W.

Re: state of Adobe's Mars/PDFXML project?

ThomasW wrote:
> Hi all,
> 
> does anyone here know anything about the current state of Adobe's Mars
> project?  As far as I know it was planned to be a built-in feature of
> Acrobat (and Adobe Reader?), but it's pretty quiet around the whole
> thing, so I fear that Adobe might no longer be working on it.  

I suspect it has quietly died a death.

> I find PDFXML a pretty interesting thing because I would like to
> create PDF files from XML sources via XSLT. (Just in case you wonder
> why I don't want to use XSL-FO: It's mostly about creating graphical
> objects, not text. And the graphical output has to be precisely
> reproducible by any XSLT processor.)

SVG or LaTeX/PDFtricks/TiKZ

> Does anyone have any information?  Is there a future for Mars or
> should I better turn to plain SVG?

SVG would possibly require more work than LaTeX, as the LaTeX graphics 
packages are now really quite extensive.

///Peter

Re: state of Adobe's Mars/PDFXML project?

On 1 Feb., 13:29, Peter Flynn <peter.n...@m.silmaril.ie> wrote:
> ThomasW wrote:
> > It's mostly about creating graphical
> > objects, not text. And the graphical output has to be precisely
> > reproducible by any XSLT processor.)
>
> SVG or LaTeX/PDFtricks/TiKZ
>
> > Does anyone have any information? =A0Is there a future for Mars or
> > should I better turn to plain SVG?
>
> SVG would possibly require more work than LaTeX, as the LaTeX graphics
> packages are now really quite extensive.
>

Peter, thanks for you advice.  It tells me once more that I really
should learn LaTeX (I was about to do so more than once, but - oh
well...).  However, I'm pretty sure that SVG, either with Mars or
without it, is the right thing for the purpose.  The source XML will
already be pretty graphical in nature, only on a more semantic level.
It will closely correspond with the to be created SVG tree.

Thomas W.

Re: state of Adobe's Mars/PDFXML project?

ThomasW wrote:
> Peter, thanks for you advice.  It tells me once more that I really
> should learn LaTeX (I was about to do so more than once, but - oh
> well...).  

http://latex.silmaril.ie/ is a good introduction (mine, so I'm biased), 
and it lists lots of other online sources. It also needs updating... 
<sigh/> when I get a little more time...

> However, I'm pretty sure that SVG, either with Mars or without it, is
> the right thing for the purpose.  The source XML will already be
> pretty graphical in nature, only on a more semantic level. It will
> closely correspond with the to be created SVG tree.

Definitely use SVG for creating graphical objects. But if you create PDF 
objects from them, they can easily be embedded in any document using 
LaTeX (and lots of other systems too). As with most of these things, use 
XML for the master version; create something else from it when needed.

///Peter

Re: state of Adobe's Mars/PDFXML project?

On 1 Feb., 13:29, Peter Flynn <peter.n...@m.silmaril.ie> wrote:
> ThomasW wrote:
> > It's mostly about creating graphical
> > objects, not text. And the graphical output has to be precisely
> > reproducible by any XSLT processor.)
>
> SVG or LaTeX/PDFtricks/TiKZ
>
> > Does anyone have any information? =A0Is there a future for Mars or
> > should I better turn to plain SVG?
>
> SVG would possibly require more work than LaTeX, as the LaTeX graphics
> packages are now really quite extensive.
>

Peter, thanks for you advice.  It tells me once more that I really
should learn LaTeX (I was about to do so more than once, but - oh
well...).  However, I'm pretty sure that SVG, either with Mars or
without it, is the right thing for the purpose.  The source XML will
already be pretty graphical in nature, only on a more semantic level.
It will closely correspond with the to be created SVG tree.

Thomas W.

state of Adobe's Mars/PDFXML project?

Hi all,

does anyone here know anything about the current state of Adobe's Mars
project?  As far as I know it was planned to be a built-in feature of
Acrobat (and Adobe Reader?), but it's pretty quiet around the whole
thing, so I fear that Adobe might no longer be working on it.  I find
PDFXML a pretty interesting thing because I would like to create PDF
files from XML sources via XSLT.  (Just in case you wonder why I don't
want to use XSL-FO:  It's mostly about creating graphical objects, not
text.  And the graphical output has to be precisely reproducible by
any XSLT processor.)

Does anyone have any information?  Is there a future for Mars or
should I better turn to plain SVG?

Thomas W.

Re: state of Adobe's Mars/PDFXML project?

ThomasW wrote:
> Hi all,
> 
> does anyone here know anything about the current state of Adobe's Mars
> project?  As far as I know it was planned to be a built-in feature of
> Acrobat (and Adobe Reader?), but it's pretty quiet around the whole
> thing, so I fear that Adobe might no longer be working on it.  I find
> PDFXML a pretty interesting thing because I would like to create PDF
> files from XML sources via XSLT.  (Just in case you wonder why I don't
> want to use XSL-FO:  It's mostly about creating graphical objects, not
> text.  And the graphical output has to be precisely reproducible by
> any XSLT processor.)
> 
> Does anyone have any information?  Is there a future for Mars or
> should I better turn to plain SVG?
> 
> Thomas W.

There is a thread on the adobe developer's forum for
Mars General Discussion
with Topic tile 'Any word on the path forward'

http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?forumid=72&catid=620&threadid=1335044&enterthread=y

One message, from Matt Hardy (09/16/2008), looks particularly relevant 
to you:

Just to follow up on some of these comments. We have just released the 
new version of Mars/PDFXML. This new version is fully compliant with the 
PDF features available in Acrobat 9.

dcpetersen: Not sure if you are still checking these forums, but have 
you considered creating a PDF Portfolio using PDFXML Syntax. That lets 
you embed native file types such as SWF, FLV (Flash Video), Images, 
Sound, etc. directly into a "package" that can then be viewed directly 
from within Adobe Reader (or of course Acrobat 9 Professional). If you 
want an example of how to do this, go to the Mars Adobe Labs Site and 
check out our Samples. We have a new one that shows how to create a 
Portfolio in PDFXML.

Re: state of Adobe's Mars/PDFXML project?

On 1 Feb., 10:57, Ken Starks <stra...@lampsacos.demon.co.uk> wrote:
>
> There is a thread on the adobe developer's forum for
> Mars General Discussion
> with Topic tile 'Any word on the path forward'
>

Yes, thanks, I already read that post from September 16th 2008.  That
seems to be the last official information from Adobe that reached the
public (about Mars, of course).  I just want to make sure that I don't
waste my time on PDFXML in vain.  I sent an e-mail to one of the Mars
contact addresses a week ago, but didn't get a reply (yet).  I should
try once more, though.  It wouldn't be the first time an e-mail got
lost on its way (or devoured by a hungry spam eating monster).

Thomas W.

Re: state of Adobe's Mars/PDFXML project?

ThomasW wrote:
> On 1 Feb., 10:57, Ken Starks <stra...@lampsacos.demon.co.uk> wrote:
>> There is a thread on the adobe developer's forum for
>> Mars General Discussion
>> with Topic tile 'Any word on the path forward'
>>
> 
> Yes, thanks, I already read that post from September 16th 2008.  That
> seems to be the last official information from Adobe that reached the
> public (about Mars, of course).  I just want to make sure that I don't
> waste my time on PDFXML in vain.  I sent an e-mail to one of the Mars
> contact addresses a week ago, but didn't get a reply (yet).  I should
> try once more, though.  It wouldn't be the first time an e-mail got
> lost on its way (or devoured by a hungry spam eating monster).
> 
> Thomas W.

I didn't refer to that post because I recommend PDFXML, I don't.

Building up your skills at SVG is likely to be a much better
investment of your time and effort.

But post-production conversion from SVG to PDF is not entirely
trouble-free, if you use open-source software. (Layers,
Transparency, font inclusion/substitution, shading and pattern 
dictionaries, ... there is more to it than you might think. )
The Apache Batik project is the most advanced, to my knowledge.
Adobe still seem to want you to buy Illustrator and convert to
PDF from there, greedy people (IMHO).

Even on the commercial side, XSL-FO processors don't always
do full credit to SVG graphics without an extra-cost optional
add-on.

As you considered the PDFXML route, I presume you prefer to generate
your graphics from another data-source rather than an interactive
application such as inkscape or Adobe Illustrator.

XSLT is just one possibility. As Peter has suggested, you might also
consider a LaTeX-based work-flow, such as pgf-tikz, PS-tricks, or PyX.

It seems to me that Adobe are throwing much of their XML energy into
Flex 2, their 'kind-of', 'not-quite' open way for us all to generate 
Flash-based stuff by writing to an XML format.

My conclusion is that, keeping content separate from presentation, you 
need an common format for your data-source that is capable---at least
in principal---of auto-conversion to each of the above outputs.

My own main current project is in mapping. The main output formats are
.kml (Google Earth) and .svg, but I am keeping half-an-eye on pgf/tikz
as a future possibility.

Bye for now,
Ken.

Re: state of Adobe's Mars/PDFXML project?

On 2 Feb., 16:52, Ken Starks <stra...@lampsacos.demon.co.uk> wrote:
>
> But post-production conversion from SVG to PDF is not entirely
> trouble-free, if you use open-source software. (Layers,
> Transparency, font inclusion/substitution, shading and pattern
> dictionaries, ... there is more to it than you might think. )

That's exactly the problem that PDFXML would solve:  Essentially, it's
an SVG dialect that is designed to be 100% compatible with PDF, i.e.
conversion back and forth between traditional PDF and PDFXML is
possible without loss of information.  (If Mars dies, the SVG pages
inside the PDFXML zip archive should still be readable by usual SVG
apps if I can avoid PDF-specific SVG extensions.)

> The Apache Batik project is the most advanced, to my knowledge.
>

Yes, I'll probably use Batik for rendering.

> As you considered the PDFXML route, I presume you prefer to generate
> your graphics from another data-source rather than an interactive
> application such as inkscape or Adobe Illustrator.
>

Actually I'd want to create a special purpose interactive application
myself.

> XSLT is just one possibility. As Peter has suggested, you might also
> consider a LaTeX-based work-flow, such as pgf-tikz, PS-tricks, or PyX.
>

I hardly know anything about those, but I don't think they would allow
me to manipulate some elements of the source data and update the
corresponding graphical elements, would they?  With XML and SVG that
shouldn't be too difficult, I think.

>
> My conclusion is that, keeping content separate from presentation, you
> need an common format for your data-source that is capable---at least
> in principal---of auto-conversion to each of the above outputs.
>

Separation of content and presentation is not my goal, on the
contrary.  I want to precisely describe pages, but instead of
graphical primitives I want to store an XML representation of more or
less complex compound graphical objects.  Those XML representations
would have to be transformed into graphical primitives in form of SVG
nodes.

Thomas W.

Re: state of Adobe's Mars/PDFXML project?

I'm a bit too busy today to give a detailed response, but here's a quick 
one.

1. It looks to me as if you are at least three-quarters of the
way towards 'separation of content from presentation'

2. In principal, the LaTeX family of solutions can respond
automatically to a change in your source data (i.e whatever ?XML?
format your application uses internally). But it would require
a one-way pipeline stage from xMl to their own markup.

Likely to be a bit slow for interactive use; more likely a
refresh/makefile/whatever from time to time.

pdfTeX provides low-level access to to PDF format at an
object-by-object level. Heiko Oberdiek seems to be the main
man here

3. pgfTikz might be getting an SVG import filter. Google for Kjell
Magne Fauske's site. He is the main man here, i think.

4. With PxX you get the whole of python behind you. But it hasn't
got patterned fills (yet) - one of my on-the-back-boiler
projects.



ThomasW wrote:
> On 2 Feb., 16:52, Ken Starks <stra...@lampsacos.demon.co.uk> wrote:
>> But post-production conversion from SVG to PDF is not entirely
>> trouble-free, if you use open-source software. (Layers,
>> Transparency, font inclusion/substitution, shading and pattern
>> dictionaries, ... there is more to it than you might think. )
> 
> That's exactly the problem that PDFXML would solve:  Essentially, it's
> an SVG dialect that is designed to be 100% compatible with PDF, i.e.
> conversion back and forth between traditional PDF and PDFXML is
> possible without loss of information.  (If Mars dies, the SVG pages
> inside the PDFXML zip archive should still be readable by usual SVG
> apps if I can avoid PDF-specific SVG extensions.)
> 
>> The Apache Batik project is the most advanced, to my knowledge.
>>
> 
> Yes, I'll probably use Batik for rendering.
> 
>> As you considered the PDFXML route, I presume you prefer to generate
>> your graphics from another data-source rather than an interactive
>> application such as inkscape or Adobe Illustrator.
>>
> 
> Actually I'd want to create a special purpose interactive application
> myself.
> 
>> XSLT is just one possibility. As Peter has suggested, you might also
>> consider a LaTeX-based work-flow, such as pgf-tikz, PS-tricks, or PyX.
>>
> 
> I hardly know anything about those, but I don't think they would allow
> me to manipulate some elements of the source data and update the
> corresponding graphical elements, would they?  With XML and SVG that
> shouldn't be too difficult, I think.
> 
>> My conclusion is that, keeping content separate from presentation, you
>> need an common format for your data-source that is capable---at least
>> in principal---of auto-conversion to each of the above outputs.
>>
> 
> Separation of content and presentation is not my goal, on the
> contrary.  I want to precisely describe pages, but instead of
> graphical primitives I want to store an XML representation of more or
> less complex compound graphical objects.  Those XML representations
> would have to be transformed into graphical primitives in form of SVG
> nodes.
> 
> Thomas W.

Re: state of Adobe's Mars/PDFXML project?

On 3 Feb., 11:31, Ken Starks <stra...@lampsacos.demon.co.uk> wrote:
> I'm a bit too busy today to give a detailed response, but here's a quick
> one.
>

Your help is really kind.

>
> 2. In principal, the LaTeX family of solutions can respond
> automatically to a change in your source data (i.e whatever ?XML?
> format your application uses internally). But it would require
> a one-way pipeline stage from xMl to their own markup.
>
> Likely to be a bit slow for interactive use; more likely a
> refresh/makefile/whatever from time to time.
>

That's crucial.  Things like mouse dragging will have to be supported
with decent redraw rates.  It appears to me that SVG is excellently
suited for that purpose because one could make use of its built in
interaction event handling features and redrawing capabilities.  My
impression is that a LaTeX/PDF approach would be much less convenient
(and too slow, as you pointed out).

For the PDF conversion part, I think I'll restrict myself to a subset
of SVG that can be be converted to PDF without trouble.  I probably
won't need transparency, gradients, layers and that kind of stuff.

Thomas W.

Re: state of Adobe's Mars/PDFXML project?

ThomasW wrote:
> Hi all,
> 
> does anyone here know anything about the current state of Adobe's Mars
> project?  As far as I know it was planned to be a built-in feature of
> Acrobat (and Adobe Reader?), but it's pretty quiet around the whole
> thing, so I fear that Adobe might no longer be working on it.  

I suspect it has quietly died a death.

> I find PDFXML a pretty interesting thing because I would like to
> create PDF files from XML sources via XSLT. (Just in case you wonder
> why I don't want to use XSL-FO: It's mostly about creating graphical
> objects, not text. And the graphical output has to be precisely
> reproducible by any XSLT processor.)

SVG or LaTeX/PDFtricks/TiKZ

> Does anyone have any information?  Is there a future for Mars or
> should I better turn to plain SVG?

SVG would possibly require more work than LaTeX, as the LaTeX graphics 
packages are now really quite extensive.

///Peter

Re: state of Adobe's Mars/PDFXML project?

On 1 Feb., 13:29, Peter Flynn <peter.n...@m.silmaril.ie> wrote:
> ThomasW wrote:
> > It's mostly about creating graphical
> > objects, not text. And the graphical output has to be precisely
> > reproducible by any XSLT processor.)
>
> SVG or LaTeX/PDFtricks/TiKZ
>
> > Does anyone have any information? =A0Is there a future for Mars or
> > should I better turn to plain SVG?
>
> SVG would possibly require more work than LaTeX, as the LaTeX graphics
> packages are now really quite extensive.
>

Peter, thanks for you advice.  It tells me once more that I really
should learn LaTeX (I was about to do so more than once, but - oh
well...).  However, I'm pretty sure that SVG, either with Mars or
without it, is the right thing for the purpose.  The source XML will
already be pretty graphical in nature, only on a more semantic level.
It will closely correspond with the to be created SVG tree.

Thomas W.

Re: state of Adobe's Mars/PDFXML project?

ThomasW wrote:
> Peter, thanks for you advice.  It tells me once more that I really
> should learn LaTeX (I was about to do so more than once, but - oh
> well...).  

http://latex.silmaril.ie/ is a good introduction (mine, so I'm biased), 
and it lists lots of other online sources. It also needs updating... 
<sigh/> when I get a little more time...

> However, I'm pretty sure that SVG, either with Mars or without it, is
> the right thing for the purpose.  The source XML will already be
> pretty graphical in nature, only on a more semantic level. It will
> closely correspond with the to be created SVG tree.

Definitely use SVG for creating graphical objects. But if you create PDF 
objects from them, they can easily be embedded in any document using 
LaTeX (and lots of other systems too). As with most of these things, use 
XML for the master version; create something else from it when needed.

///Peter

Re: state of Adobe's Mars/PDFXML project?

On 1 Feb., 13:29, Peter Flynn <peter.n...@m.silmaril.ie> wrote:
> ThomasW wrote:
> > It's mostly about creating graphical
> > objects, not text. And the graphical output has to be precisely
> > reproducible by any XSLT processor.)
>
> SVG or LaTeX/PDFtricks/TiKZ
>
> > Does anyone have any information? =A0Is there a future for Mars or
> > should I better turn to plain SVG?
>
> SVG would possibly require more work than LaTeX, as the LaTeX graphics
> packages are now really quite extensive.
>

Peter, thanks for you advice.  It tells me once more that I really
should learn LaTeX (I was about to do so more than once, but - oh
well...).  However, I'm pretty sure that SVG, either with Mars or
without it, is the right thing for the purpose.  The source XML will
already be pretty graphical in nature, only on a more semantic level.
It will closely correspond with the to be created SVG tree.

Thomas W.