Hi, folks. Hope you are having a nice Sunday
Just allow me two simple question about the use of sidecar.xml files to speed up and simplify the upload-building of a DPS publication.
1. I place a sidecar.xml file in the root of the folder structure. It seems to need that structure to be very simple (no nesting of folders?, All right I can live with that). The folders follow one given order (alphabetic, let's say. It's irrelevant) . Now I want the uploaded articles in DPS to follow the order I described them in the sidecar.xml (another one, completely different). That does not happen: The articles are uploaded and placed with the order of the folders (and that's is something I cannot live with, because it defeats the speeding up purpose of a sidecar.xml). Any idea? Am I doing something wrong?
2. Is there any way (xml tag) I can specify in the sidecar.xml the thumb picture I want to use in the TOC in the Content wiever?
3. The lenght of headlines-titles in the sidecar seems to be too short. Any idea if that is a shortcoming of the sidecar generator or else?
Though I am using the excellent sidecar generator of Johannes Henseler, somehow I think the three questions is unrrelated to it.
Thanks a lot
Gustavo Sánchez (Posting from a scorching sunny Madrid).
@Gustavo – Can you reveal some of your sidecar.xml code using advanced editor of the forum: >> (Insert) / Syntax Highlighting / Java? And a list of your Folders/Files structure. A short example that is showing the problem will do.
Thanks for answering. Here there is an example (names and content changed) of my settings:
and this is the sidecar.xml for that structure:
<?xml version="1.0" encoding="UTF-8" standalone="true" ?>
sidecar.xml generator by Johannes Henseler
Built on 2012-6-24 using version 0.5 of the generator.
To edit this sidecar, import it into the generator again.
<!-- article #1 -->
<articleTitle>Welcome to Mordor</articleTitle>
<description>Here, you'll neer walk alone.</description>
<!-- article #2 -->
<articleTitle>Welcome to horseland</articleTitle>
<description>The land of the green fields</description>
<!-- article #3 -->
<articleTitle>Welcome to Hobbiton</articleTitle>
<description>The hobbits live here. Come and see!</description>
<author>Gandalf the Grey</author>
(Hope the code pastes all right)
Is the folder name "Mordor" or "02 Mordor"? The field in the sidecar.xml file needs to match the folder name exactly.
If you put the thumbnail .png in the article folder on the same level as the InDesign files, it will be picked up automatically when you import the article.
Metadata fields are limited to avoid the cropping of text when the artcle is displayed in the viewer.
Well. Here, may be, lies the thing: The name of the folder, the InDesign files and the article exported are not exactly the same. I thought that the match was mandatory only between the article AND the name in the sidecar. So... I guess I just have to change the names of the folders to match exactly the name of the exported articles (no white spaces, just_in_case).
That answers, I guess, my question about the nesting of folders (for our internal sorting of sections purposes): No way.
I overlooked the thumbs things.
Thanks a lot
Back to my guscave.
@Bob Bringhurst – I think it would be time to exceed the capabilities of the sidecar.xml file with something like this:
<folderPath>..\root of project\01 hobbiton</folderPath> <articleName>hobbiton</articleName>
where <folderName></folderName> will not be deprecated (for compatibility cases with old sidecar.xml files).
A relative path description and tags that are semantically more clear.
Of course it is debatable if we use <folderPath> or <directoryPath> or, even better: <articlePath>.
@Bob – good to know…
Of course also the ability to generate a sidecar.xml file out of an existing project together with an editor (maybe a panel) where you can point to folders.
Basically all the information is there. The only thing is that it's very hard to get to them (for building up a tree view with all assets of a folio or an article in case for reporting and getting an overview) and we (the scripters) have nearly no means ("methods" or "functions") to access the pieces.
There is a app.createCustomMiniFolio() method, not documented very well, but there is no "app.folio" (Folio) object in the DOM or a "miniFolio" (Article) object.
There is a app.exportFolioToDirectory() method, but no app.importFolioFromDirectory() method.
It would be good to have an add() method for creating new folios with all needed properties (all pseudo code here using a made up "folioBuilder" object):
size:"1024 x 768",
and an add() method for creating articles inside an existing folio like that:
or a move() method for moving articles around in a folio or even to another folio:
"app.folioBuilder.folios.itemByName("MyFolioName").miniFolios.itemByNa me("MyArticleName1").move(LocationOptions.AT_BEGINNING, app.folioBuilder.folios.itemByName("MyOtherFolioName"))
Hope, you'll get the picture…
Of course offering something like that will slow down development of new DPS versions, but also will open doors for 3rd party developers wide open with new, fresh tools (scripts, custom made panels) and ideas.
Same goes with Overlay Creator panel.
Another example how we can make progress in scripting DPS:
Annotation: all overlay properties applied to an InDesign page item are applied by invisible labels, that stick to that item.
What went wrong: a tiny change from InDesign CS5.5 to InDesign CS6!
For scripting we had a method in InDesign CS5.5 for detecting all applied labels (insertLabel() method), that is not functional any more with InDesign CS6:
without specifying a key string in "()" the function will not return an array of ALL the key/value pairs any more (great feature in Indesign CS5.5!). Instead we have to gather those information by exporting the page item to an IDMS file and extracting the information from there. A step backwards in ease of use. Please, bring the old functionality back…
For a detailed discussion in the scripting forums see:
Europe, Middle East and Africa