Skip navigation
Currently Being Moderated

Sidecar.xml first generation

Jul 11, 2012 12:36 AM

Tags: #dps #sidecar

Johannes granted us with the excellent : http://projects.nordsueddesign.de/sidecarxml/ so that we can organize and easily manipulate elements of a large publication.

The thing is it requires a "first time generation" which seems to have to be done manually, filling each folio name, description, etc.

 

Basically, this xml manipulation is done inside the Folio Builder panel, or the Folio Producer website. And it's "invisible" to the user.

 

I don't see, and think we would require, an export option once a folio is organized, to generate this very first xml.

 

Second thing is this tool is hosted freely by Johannes, when i suppose it should be hosted directly by Adobe, at the very least mentionning the creator and owner of this priceless tool.

 

 

 

 

I also saw a discussion here http://forums.adobe.com/message/4031557 and wonder : We can update the sidecar xml alone. But it seems to require to process again all the present data, images, and send again online, when it only has to change properties and the order of the pages. Shouldn't there be a way to update ONLY this meta file in the folio/different articles ? Just thinking of the process and bandwidth for a 300MB folio when a 50k xml is all that changed…

 

 

PS : we need a "vote for ideas" option somewhere here, no ?

 
Replies
  • Currently Being Moderated
    Jul 11, 2012 1:27 AM   in reply to Franck Payen

    thank you Franck for your nice words. I like that I could help a few people

    out with this generator that I initially only made for myself.

     

    now that we require renditions, sidecars are more important than ever.

    normally, I create everything in the sidecar at first, don't edit metadata

    in the folio builder panel/organizer.

     

    Bob Bringhurst somewhere mentioned a possible "export" function where you

    can then transfer the metadata, wich is on some roadmap.

     

    but the requirement of such a file is wrong at the first place. instead of

    duplicating a folio two, three, four or five times (iPad2,3, Android,

    iPhone 3,4) this should be an integrated process.

     

    a folio should have defined "targets" inside: iPad, retina, android. and

    when Adding an article, all required 'internal renditions' should be

    generated automaticlly by upscaling and/or picking the right alternative

    layout.

     

    I think this would be the correct architecture for renditions and it is an

    approach we see by many multi device workflows (especially iOS app design).

     

    but now I am turning this thread into a discussion about renditions.

     

    sidecar.XML is good, but does not cover all things, like preview files or

    article format, so there might be an improvement as well.

     

    the code of my sidecar generator is also available on github for everybody

    to grab, improve and host (or check changes back in).

     

    —Johannes

     

    (mobil gesendet)

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (1)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points