Skip navigation
Currently Being Moderated

Is CS5.5 IDML a bug?

Nov 19, 2011 9:06 AM

Tags: #error #export #indesign_cs5.5 #5.5

Hi All,

 

While opening 5.5 IDML file in CS5/4 InDesign quits. This happens in xml and non-xml documents, sometimes InDesign get hangs with showing progress bar. Even I have waited for more than an hour and its waste of time. Have anyone faced this problem before or is it a bug in cs5.5?

 

thanks

Jaswin

 
Replies 1 2 Previous Next
  • Currently Being Moderated
    Nov 19, 2011 9:25 AM   in reply to Jaswin

    Quits, as in shuts down and disappears, or hangs as in stops reponding and shows you the spinning beachball of death?

     

    Do you see any sort of error  messages at all? What do they say? Have you tried emptying the InDesign Recovery folder to be sure a corrupt file from a previous crash/hang is not stuck in a loop of failure on start?

     

    What is the OS?

     

    What do you know about the .idml files, if anything, in terms of what they contain?

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 19, 2011 10:37 AM   in reply to Jaswin

    I really don't know very much about the internal structure of .idml, but it is certainly more complex than .inx, and I would be surprised if CS5.5 .idml was not more complex than CS5 or CS4.

     

    I have personally seen .idml files that take over an hour to open, but it isn't common. Lots of complex vector data embedded rather than linked was the culprit. That's why I asked what you knew about the content. If you have an idle machine, you might want to give it another shot and let it sit overnight. Do you have a system with CS5.5 to try on, as well?

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Nov 19, 2011 7:03 PM   in reply to Jaswin

    And Im sure the file is not corrupted. I use XP.

    That's a very strong statement! How do you know? Generally IDML files that cause crashes are indeed corrupt.

    If you can't open it in anything, unzip it, and start commenting pieces of the DesignMap.xml file out, and zip it back up. You should be able to narrow down the portion of the IDML file that is causing the problem.

     

    But please do answer the question above -- what reason do you have to think your IDML file is not corrupt?

     

    When Peter asks about what the IDML files contain, I don't think he is asking you about IDML files in general. He is asking about your files. What makes this IDML file different from all others, yes?

    IDML is a XML format, but that is not the same as we export the XML from InDesign. It gets all information about the document and helps to retain the same in lower version and similar to inx. More than an inx file IDML helps to automate InDesign document. This is what my idea about IDML, am I right Peter?

    IDML isn't like ID's XML export, but it is totally like INX.

    Peter wrote:

    I really don't know very much about the internal structure of .idml, but it is certainly more complex than .inx, and I would be surprised if CS5.5 .idml was not more complex than CS5 or CS4.

    Actually, it's not really more complex than INX. In general IDML is INX with the tags renamed from 4-character abbrevations like <pstr> to more verbose names like <ParagraphStyleRange/>. And then split into multiple files that are all zipped up. But from a complexity standpoint, at least what I would call complexity, it's the same. They represent the same information in basically the same kind of encoding.

     

    Anyhow, I think it's unequivicobly a bug. Even if it ultimately succeeds overnight, there's no way ID should take minutes to open such files without giving meaningful progress indications... Though the fix might only be to add such progress indications if that's what is going on...

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 20, 2011 2:10 AM   in reply to John Hawkinson

    John,

     

    I don't really mean to argue semantics with you, but it seems to me that a zipped package contaning several xml files is more "complex" than a single file, regardless of how the information is conveyed once decompressed. There are more chances for error in either the compression or decompression I would think.

     

    As far as a bug, I don't know. The progress indicator may be telling the truth and the file is hung looking for something (that would be my guess) or drawing previews for some hugely complex vectors (the other slow, but openable, .idml files I've seen -- and why it should take so long, I don't know, when the .indd opens fine, except perhaps the .indd has the previews embedded and they got drawn in real time as the objects were added). For what it's worth, I too suspect the .idml file may be corrupt. Perhaps it was copied before it was completely written.

     

    @ jaswin,

     

    Where are all of these images stored?

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 20, 2011 3:15 AM   in reply to Jaswin

    Linked images would definitely be better than embedded. Did you have any luck with the longer wait?

     

    Do you still have CS5.5 available? You might want to try exporting again (and wait a few minutes before accessing). I would also recomment that you NOT export directly to removable media, if you have been. I'd be happy to try exporting here, too if you like. Let me know and I'll send you an upload link for the .indd.

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 20, 2011 3:41 AM   in reply to Jaswin

    When you save the .idml it would be best to save it on your hard drive, not a network location, and especially not on an external drive or USB flash drive. You can move it to one of those locations after it is finished, but external locations tend to have more issues with read/write errors during file creation that cause corruption (and if the .idml is on a an external drive, it might work better on your hard drive, too).

     

    I had one .idml file from another user here on the forum that took, as I recall, over two hours to open, but eventually it did.

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Nov 20, 2011 6:34 AM   in reply to Jaswin

    That's a very strong statement! How do you know? Generally IDML files that cause crashes are indeed corrupt.

    Hi John, I mean the InDesign files not the IDML, from your view the exported IDML is corrupted.

    Your language is getting confusing, so I'm going to take this in small portions. OK, I understand you mean the INDD file is not corrupted.

     

    Same question: How do you know? Corruption in an INDD file can be subtle! Sometimes you only discover it when you try to perform an operation that interacts with a particular page object or item attribute. For instance, suppose there is an item with nonsense coordinates, 10 miles (16 km) off the edge of the page. InDesign may write that information just fine to the INDD file. It may even write it to the IDML file. But when it reads the IDML file and tries to construct its idea of the page layout as it prepares to render the document, suddenly this huge object in a faraway place may cause simple calculations to become not-so-simple, and small numbers to become huge, and small processing times to become long processing times.

     

    If the exported IDML corrupts then what might be the problem with CS5.5?

    Oh, definitely. I mean, something is either buggy or corrupt, and if is corrupt, the corruption had to come from somewhere.It could be the operating system's fault, but most likely it is InDesign's fault, and if you changed from CS5 to CS5.5 recently and observed a difference, CS5.5 is probably at fault, no question. If you can find a clear reproducible test case, I'm sure Adobe would be interested in fixing it.

     

    Peter:

    I don't really mean to argue semantics with you, but it seems to me that a zipped package contaning several xml files is more "complex" than a single file, regardless of how the information is conveyed once decompressed. There are more chances for error in either the compression or decompression I would think.

    You probably realize I have no problem having a friendly discussion about semantics, though I did say, "at least what I would call complexity" I guess because I suspected some might use a different definition :-). It turns out, though, that it's actually harder to corrupt a compressed file without detection. For two reasons. First, because zip files contain checksums, and if the uncompressed file doesn't match the checksum, then the unzip tool will throw it away and give up. Second, because it is compressed, any single bit-error in the compressed file will show up in multiple places in the uncompressed file. That tends to mean that it's very hard to change something like TextColumnCount="1" into TextColumnCount="9" without other changes elsewhere, like maybe "TextColumnCount" would become "TextZolumnCount." And while the IDML parser might not recoginize that the value 9 is invalid and should be 1, it can indeed recognize the difference between Column and Zolumn. And becaue XML files have symmetric structure with <opentag>blah blah </closetag>, any sort of corruption of has a good chance of unbalancing the tags, which is easy to detect.

     

    So, for the foregoing three (two?) reasons, it turns out that ZIP files are more robust than you might suspect, even to the point where they are more protected than most non-ZIP files that don't contain CRCs and other checksums. (I'm not sure what checksums INDD files have.)

     

    For what it's worth, I too suspect the .idml file may be corrupt. Perhaps it was copied before it was completely written.

    It turns out this is hard to happen, too. Because in .ZIP, there ia an index of all the files contained in a ZIP file, called the Central Directory. The Central Directory is written at the end of the ZIP file. So if a ZIP file is prematurely or partially copied, it won't have a valid Central Directory structure. I suspect the uncompressed contents of the IDML file is staged to a temporary location on your hard drive and then the IDML/ZIP file is written out to the destination device from that, so there is little need for the user to add an extra level of staging to the hard drive to avoid removable media issues...

     

    Anyhow, enough theory, back to the problem!

    I wrote initially:

    If you can't open it in anything, unzip it, and start commenting pieces of the DesignMap.xml file out, and zip it back up. You should be able to narrow down the portion of the IDML file that is causing the problem.

    Jaswin, did you understand me? Are you comfortable trying that?

    I still think that's the way to go.

     

    If not, could you post one of the problem files publicly? Or perhaps email it to me?

    Thanks.

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 20, 2011 12:19 PM   in reply to Jaswin

    Hi Peter and John!

     

    I m also having same kind of problem with no of files when I exported IDML from ID CS 5.5. I did not face these kind of issue in ID CS 5. Recently I am facing this issue. I have already searched in the forum. But I did not found any answer.

     

    Thanks

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 20, 2011 12:24 PM   in reply to Jaswin

    It might help if both of you were able to supply a sample file....

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 21, 2011 6:54 AM   in reply to Jaswin

    Can you share privately?

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 23, 2011 2:36 AM   in reply to Jaswin

    Downloading now. I'll try to get back to you in a few hours.

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 23, 2011 2:40 AM   in reply to Jaswin

    What are the two "untitled" files?

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 23, 2011 3:06 AM   in reply to Jaswin

    If he has time, I think John should look at these files. I'm pretty sure whatever is wrong is due to the XML structure. I've had only crashes, not hangs, withthe IDML you sent, and My system crashes when I try to make my own from your .indd.

     

    If I export the story to tagged text and bring that into a new file (which removes the XML tagging) I have no problems making or opening a new .idml, but I don't know enough about XML to know how to remove the tagging from the original without removing the content too to test if that's enough.

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Nov 23, 2011 3:18 AM   in reply to Peter Spier

    John is about to go to sleep, but feel free to email it to me and I'll take a look later today.

    I believe XML tags are stored in the XML/ subdir of the IDML file, in BackingStory.xm and Tags.xml.

    I would just try deleting those files.

     

    But again, you can comment pretty much anything out the IDML files (esp. designmap.xml), and InDesign will still open it,

    though of course large swaths of stuff may be missing. But it's a great way to find the problem...

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 23, 2011 3:25 AM   in reply to Jaswin

    Jaswin wrote:

     

    You just leave the 'untitled' files, What about the other files? If you had crashes with that files too how can this one be solved? Please pass those files to John, let us know whats sort of problem he face.

    No, I was working with your actual .indd files (#1 & #6). I'll pass the files on to John for you.

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Nov 23, 2011 3:48 AM   in reply to Jaswin

    Ok, well, this is definitely too big for me to deal with right now, got to get to bed before the sun comes up .

    What's our goal here? To get the files in CS4? Do they need XML structure there? Any deadlines?

     

    Looking at your 00 files, there's a lot to be concerned about. Opening the IDML in CS5, I crash in the IDML INX parser. This is probably not because of the document's XML structure, but maybe. It's probably instead because the IDML itself is damaged somehow.

     

    I do not crash exporting the IDML from CS5.5.

     

    Editing the IDML's designmap and removing the references to the three XML/* files, the 00 file opens just fine, except that the main content of the textframes is missing. This is inconsistent with the above analysis ("not because of the document's XML structure") and also downright strange, since the three XML files don't really have anything to do with the content of the story.

     

    Anyhow, it's clearly going to take some time to track down the problem. So..."later."

    What time zone are you in, Jaswin?

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Nov 23, 2011 10:25 AM   in reply to Jaswin

    I'm not really here quite yet, but please do answer the questions I asked:

     

    What's our goal here?

     

    To get the files in CS4?

     

    Do they need XML structure there?

     

    Any deadlines?

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Nov 23, 2011 4:57 PM   in reply to Jaswin

    OK, I had some time to look at this, and I'm afraid the problem is not simple.

    It is highly correlated with XML, though, so please do answer the questions I asked.

     

    I think you will need to get comfortable looking inside IDML files in order to make good progress here. Remember they are just .ZIP files. You can unzip them, edit their contents, and zip them back up.

     

    I spent a while examining your 00.idml file. Like all IDML files, designmap.xml is the overall index to the document, and it defines what portions are present.

    Your designmap indicates that there are 46 stories in your document. That seems like a lot for your 3-page document, but OK.

     

    It turns out that commenting out the first story is sufficient to make the IDML file open. That is, editing the designmap to look like this, around line 133 and following:

     

    <idPkg:BackingStory src="XML/BackingStory.xml"/>
    <!-- <idPkg:Story src="Stories/Story_u3079.xml"/> -->
    <idPkg:Story src="Stories/Story_u3057.xml"/>
    <idPkg:Story src="Stories/Story_u3010.xmxl"/>
    <idPkg:Story src="Stories/Story_u2c62.xml"/>
    

     

    It's curious that it is the first story.  Opening the resulting IDML file is interesting. Itl ooks like your document is actually the same, but there is some slight text reflow, and it fits on 2 pages instead of 3. I find that quite surprising -- I would have expected an entire story to have disappeared, and that did not seem to happen.

     

    Of course, this doesn't exactly tell us what the problem is. To do that, we need to look inside that story file.

    I haven't spent a lot of time looking at IDML files with a lot of XML-tagged content, but the 3079 story file looks basically like this:

     

     

    <idPkg:Story ...>
      <Story Self="u3079" ...>
        <StoryPreference OpticalMarginAlignment="false" .../>
        <InCopyExportOption IncludeGraphicProxies="true" IncludeAllResources="false"/>
        <XMLElement Self="di2i105" MarkupTag="XMLTag/outline" XMLContent="u3079">
          <ParagraphStyleRange AppliedParagraphStyle="ParagraphStyle/Chap outl 2">
            <CharacterStyleRange AppliedCharacterStyle="CharacterStyle/$ID/[No character style]">
              <XMLElement Self="di2i105i1" MarkupTag="XMLTag/ce%3alist">
                <XMLElement Self="di2i105i1i2" MarkupTag="XMLTag/ce%3alist-item">
                  <XMLElement Self="di2i105i1i2i3" MarkupTag="XMLTag/ce%3apara">
                    <XMLElement Self="di2i105i1i2i3i4" MarkupTag="XMLTag/ce%3alist">
                      <XMLElement Self="di2i105i1i2i3i4i5" MarkupTag="XMLTag/ce%3alist-item">
                        <XMLElement Self="di2i105i1i2i3i4i5i6" MarkupTag="XMLTag/ce%3alabel">
                          <Content>1.</Content>
                        </XMLElement>
    ...
                      </XMLElement>
                    </XMLElement>
                  </XMLElement>
                </XMLElement>
              </XMLElement>
            </CharacterStyleRange>
          </ParagraphStyleRange>
        </XMLElement>
      </Story>
    </idPkg:Story>
    

     

    Now, if you comment out the <ParagraphStyleRange>...</ParagraphStyleRange>, it still crashes. But if you comment out the enclosing <XMLElement> as well, it does not.

    So, it's not an issue of the particular content of the story, but rather the fact that it is XML tagged, and perhaps how the story is used. It's a lot less obvious to me. I suppose you could comment out the MarkupTag attribute, I didn't try that. But looking at XML/tags.xml, there is nothing too interesting about the outline tag.

     

    Oh, another observation is that your document does not validate against the DTD in the structure pane. That could be related.

     

    I suppose one could also open the appropriate Spreads file and fiddle with the TextFrame that is associated with Story u3079. See if associating it with another story works better. Looking at that frame casually, I don't see a real problem with it.

     

    Also, much of the stuff in story u3079 is duplicated in story u6ee. I'm not sure what that means, but it seems like it might be related to the problem -- accidental duplication of an object?

    I bet, also, we could explore more with the scripting DOM if we really got excited.

     

    Hopefully this helps you get started!! Still waiting on some context/answers to earlier questions, though.

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 24, 2011 2:39 AM   in reply to Jaswin

    I won't go into why moving a file from verion 7.5.x to version 5.0.x isn't likely to be terribly satisfactory under most circumstances, that's no reason the .idml export process should fail.

     

    Can you explain, though, what you do with the XML structure that the tags need to be preserved in CS3?

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Nov 24, 2011 7:14 AM   in reply to Jaswin

    Oh boy, the truth comes out! CS3! Well, could be worse, could be CS2!

     

    Were you able to follow my instructions? I believe you have a solution that can work. It's not exactly automatic, but it's not a complete failure either. And if you're lucky, you'll have a pattern in your other files. For instance, u7039 was the first story listed in 01. It also happens to be the 5th largest story file. Given that you have 46 story files, that certainly helps you narrow it down. (though 20 of those 46 were all the same size, 10 at 2193 bytes and 10 at 1000 bytes, so you could intuitively skip those, too).

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Nov 25, 2011 10:10 PM   in reply to Jaswin

    Please do answer my questions! It's really hard to help you when I cannot tell if you are understanding me.

    Were you able to follow my instructions?

     

    So you concluded that the problem is with story which is very large, right? How can it be ignored from the file?, we need that anyway.

    Well, no. It is not the largest story. It is the 5th largest story. Looking in a bit more detail, it appears to be the story on the pasteboard to the left of page 1, which you have tagged "outline." And indeed, if I delete that TextFrame in InDesign and then export to IDML, I can open the IDML just fine in CS5.5, where it crashed before.

     

    Unfortunately I assume you are depending on this for tagging. I'm not sure what it is about that story that causes the problem, but you should be able to play Divide and Conquer. Delete half the story, export, see if it causes the problem. If not, delete another half. If so, restore half. Etc.

     

    How was I able to identify the story?

    Well, I used scripting. I took a word that was unique to that story (well, it also appeared in the largest story), and ran:

     

    d=app.activeDocument;
    for (i=0; i<d.stories.length; i++) {
      if (d.stories[i].contents.match(/Identifier/)) { print(i); }
    }
    

    to get the story numbers (5, 45), and then ran:

     

    d.stories[45].textContainers[0].select();
    

     

    to select the frame containing story #45, and then hit Cmd-1, to zoom to it. (It turns out that u3079 is actually story id 12409, which is not surprising since 12409==0x3079. Did I wrote 7039 above? Oops! Sorry! Dyslexia, I guess. So I guess we could have just used

    app.activeDocument.stories.itemByID(0x3079).textContainers[0].select(); 
    

    )

     
    |
    Mark as:
  • John Hawkinson
    5,572 posts
    Jun 25, 2009
    Currently Being Moderated
    Dec 28, 2011 8:51 AM   in reply to Jaswin

    Well, you can keep deleting stories until you find the one that causes the problem.

     
    |
    Mark as:
1 2 Previous Next

More Like This

  • Retrieving data ...

Incoming Links

Bookmarked By (0)

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