6 Replies Latest reply on Jul 18, 2012 5:27 AM by benvanderberg

    The Perils of InDesign XSLT

    vze26m98

      Hi all-

       

      Not much of a question; if I have one it's "what's up with the XSLT processor that InDesign uses"?

       

      After several days of work with it, I'm convinced that it can't handle namespaces correctly, the most spectacular example being this attribute it managed to generate:

       

      xmlns="<DUo=>a7n)"

       

      Perhaps worse though, are the times when xmlns is given the value of "7" or something, the XSLT or XML processor dies quietly, and InDesign can import no more until the application's been restarted.

       

      I thought this might be something I'm doing wrong, but I compared my results to the Sablotron processor for WIndows that's still kicking around the Internet, and also the version that's available via Ubuntu Lucid long-term support. Both are pretty happy with the coding I've done.

       

      Why am I messing around with namespaces? Well, Filemaker. Their database export ungraciously make the default namespace "http://www.filemaker.com/fmpxmlresult", so you have to deal with that if you want to do anything.

       

      But enough flaming. I'd love to hear from anyone who's doing something reasonably complex with XSLT and InDesign. Maybe it's just OSX Lion here that's making Adobe's work seem so old.

       

      Best wishes, Charles

        • 1. Re: The Perils of InDesign XSLT
          absqua Level 4

          It's been awhile since I wrote xslt for InDesign to use on import, but I remember being underwhelmed. (I talked about this in the same non-specific way in this thread.) I don't remember having problems with namespaces though. I'd be happy to try your transform and import here if you want.

           

          I would encourage you to file bugs. I don't think InDesign's xml capabilities have been updated in quite some time. Judging from posts on this forum, it is still in heavy use.

           

          You could always use doScript and do shell script inside an Applescript to drive a command-line processor like the open-source Saxon and import the result of that.

           

          Jeff

          1 person found this helpful
          • 2. Re: The Perils of InDesign XSLT
            John Hawkinson Level 5

            You could always use doScript and do shell script inside an Applescript to drive a command-line processor like the open-source Saxon and import the result of that.

             

            Or just plain xsltproc(1) that ships with the OS...

            1 person found this helpful
            • 3. Re: The Perils of InDesign XSLT
              vze26m98 Level 1

              Thanks to you both for your kind replies.

               

              My solution needs to be cross-platform, so working with what InDesign provides makes that simpler.

               

              I now have working XSLT that isn't too ugly to look at, and produces exact copies of the required interchange XML between Filemaker and InDesign, which enables me to see trouble with a Diff tool.

               

              I'll file a bug report. Maybe some Adobe tech can take the source package from the Ubuntu repository and update InDesign.

               

              Best, Charles

              • 4. Re: The Perils of InDesign XSLT
                benvanderberg

                From what I have found in my experience the XSLT engine in InDesign sucks. I was recently trying to write XSL to bring in content. Because of the way that InDesign can be space-aware for content that will be displayed inline, we concluded it was important to strip out the additional whitespace contained in the XML unless explicitly told.

                 

                Here are some of the items we used:

                <xsl:template match="text()" />

                    <xsl:strip-space elements="*"/>

                    <xsl:output method="xml" indent="no" encoding="UTF-8" />

                The problem with this is InDesign completely ignores this. If I run this separately in any other XSLT engine, it will run perfectly fine. If I have InDesign handle it, it ignores any of these instructions. Does this essentially mean that I will be forced to have to do any of the transformation outside of InDesign?

                • 5. Re: The Perils of InDesign XSLT
                  absqua Level 4

                  Does checking "Do not import contents of whitespace-only elements" (which seems the equivalent of <xsl:strip-space>) not give you what you need?

                   

                  Here's a hacky workaround if not. You can explicitly match whitespace-only text nodes and then do nothing with them:

                   

                  <xsl:template match="text()[string-length(translate(., ' &#9;&#xA;&#xD;', '')) = 0]"/>
                  

                   

                  Jeff

                  • 6. Re: The Perils of InDesign XSLT
                    benvanderberg Level 1

                    I tried doing the white-space only elements setting with no luck. I am going to play with some other options of explictly finding some of the whitespace and removing it. It just is annoying that every other XSLT engine I have tried will work properly EXCEPT for InDesign