InDesign and DITA (webinar)
Jake Campbell talks about how you can utilize automated processes in a high-design environment.
“When we’re looking at high-design, we have a focus on form. When we’re looking at automated workflows, we’re looking at a focus on the content itself.”
—Jake Campbell
Related links:
- DITA to InDesign: getting your paragraph styles in order
- InDesign XML for well-designed print layouts
- Highly designed content (podcast)
- High return on high-design in DITA
Twitter handles:
Transcript:
Elizabeth Patterson: Hi, everyone, and welcome to The Content Strategy Experts Webcast. I’m Elizabeth Patterson, and I’ll be moderating this presentation today. Jake Campbell will be presenting InDesign and DITA. The Content Strategy Experts Webcast is brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. If you’re new to DITA and need some introductory training, please visit LearningDITA.com for free online courses.
EP: Attendees are going to be muted during this webcast, but we still want your input during the session. Some of you have already submitted questions when you registered, and we will address those during the Q&A portion of this webcast. However, if you have any additional questions that come up, please feel free to submit them at any time in the questions module, and Jake will answer those at the end of the session. If you would, go ahead and locate the questions module in the GoToWebinar interface, so that you know where that is. Also, be on the lookout during the question and answer portion of the presentation for a link to our evaluation survey. We would really appreciate your feedback. And with that, I’m going to go ahead and pass things off to Jake. Jake, are you ready?
Jake Campbell: Yep, I’m all set.
EP: All right.
JC: Okay. Hi, everybody, and welcome to our little discussion on InDesign and DITA, specifically utilizing DITA source content to create an InDesign output. Just as a quick introduction, like Elizabeth said, I’m Jake Campbell. I’m a technical consultant at Scriptorium Publishing. I spend my time doing plugin development and a little bit of content strategy. In my spare time, I like to play and design board games, and if you like, you can follow me on Twitter @JakeScriptorium.
JC: Let’s go ahead and just dive into what we’re going to be covering. We’re going to start out by talking about the concepts of high design, specifically what InDesign is and the differences between desktop publishing and automated publishing, how InDesign requirements can inform your DITA and vice versa. Then we’re going to talk about the actual DITA-to-InDesign process, and we’ve got a little demo in there too, just to show you where we’re standing. And then we’ll close out by talking about when to choose DITA-to-InDesign. What makes it worthwhile to do that?
JC: There are a few ways that you can come at considering a DITA-to-InDesign workflow. For now, let’s go with this hypothetical. Just imagine that your goal is print or PDF output. You currently have a high-design workflow through InDesign with a dedicated team. And you’ve got your content creators starting to transition to offering their content in DITA. The question is, how do you integrate those workflows, because they’re actually very different. Let’s jump into the concepts of high design, because we’re talking about InDesign, so we have to start out by talking about what it, like most desktop publishing software, offers, which is a high-design environment.
JC: High-design is when your layout and your styling is just as important as the content itself, like the layout and the formatting. This is especially important for things like product guides, datasheets, or other technically-involved content. I usually see this kind of content as safety information or something where there are a lot of call-outs or other ancillary information that requires very specific formatting. You can think of it like a curry. There are a ton of variations that approach the same goal, but in a very carefully crafted way that sets it apart from other foods.
JC: Let’s take a look at high-design versus automation. When we’re looking at high-design, we have a focus on form. When we’re looking at automated workflows, we’re looking at a focus on the content itself. High-design also is generally very platform-specific. If you make something in InDesign or FrameMaker, you’re generally locked into that platform, whereas with an automated workflow you can transport that between platforms with relatively little problem. High-design has a wide array of formatting variations. You have a lot of control over what you can do. Automation can give you formatting that is consistent for days, but variation needs to be very specifically applied. One of the biggest differences between an automated workflow and a high design workflow is the level of control that the content creators have, specifically over formatting.
JC: Just to give a quick visual, high-design, you got whistles, bells, pulleys, knobs, sliders, screens. You’ve got control every which way. Whereas with automation, you got a button. You get to push the button, and if you need something to happen, you can get somebody with a toolbox to go out back and change some things, but your primary role is you get to push the button. That seems like a lot. Are these approaches actually compatible? Because it seems on its face that they’re completely at odds, and can they even work together?
JC: The answer is yes, kind of. Generally, when you’re looking at automating a high-design workflow, you can get most of the way there, like 90-95%. The remaining percentage is handled by your InDesign team, either by doing things by hand or via scripting. But the thing is, is moving to this kind of workflow actually worth it? Let’s take a look at a quick comparison between a high-design format and automated format. This is how design and automation interact. They’re both different facets of content.
JC: First, on the low automation, high-design side, you’ve got lovingly handcrafted bespoke content, something that is completely controlled by your authors, and every step of the way they have full control, but they have to do everything by hand. Then over here we’ve got fully automated, template-driven. The only content your content creators have is what content goes into it. The degree of control that they actually have over the format at any given time is relatively limited. And then over here we’ve got something that uses templates plus manual adjustments to try and automate a highly-designed area. And then over here we’ve got some content. Don’t worry about it.
JC: This is the cost for each area. Up here we’ve got design-centered content. As you start moving towards the right, you’re starting to see things like using masters and paragraph styles to help streamflow your workflow process. Maintenance is still a pretty big issue, though, since you need to go back and adjust all those knobs and sliders whenever you need to make a change. And depending on how many templates you have or how many output variations you have, that might be a lot.
JC: Then we’ve got the structured side of things. Here we’re looking at that pushbutton system that we talked about earlier. Then as we move up, we’re probably looking at things like using some scripts to make adjustments before things move to their final output. Then when you overlay them at fully automated, fully high-design, you’ve got what we call a region of doom. It’s not great. I mean, it probably looks great, but it’s very expensive and very hard to do. Basically, you’re going to be putting in a lot of work at the start, and by the end you’re going to be hitting a lot of diminishing returns on the level of perfection you’re getting at the end there.
JC: But here where we’ve got this overlap, we’ve got a pretty good value, and this is where we want to land. You don’t wind up with everything, but you wind up in a good place. And all you have to do is compromise a little on both sides, and you can make it happen. Let’s take a look at some of the benefits that you get out of the blending of these two approaches.
JC: Automation. Obviously, it’s pushbutton. You push the button, you feed something in, you get your output, and that’s it. You wind up with a direct deliverable, something that is ready to immediately hand off after you push that button. You don’t need to do anything with it afterwards, and you wind up with consistency. You don’t need to worry about something weird happening that has the formatting messed up. Once you get everything configured and set up, you should be good.
JC: And then let’s take a look at the benefits of high-design, specifically InDesign. InDesign has a lot of typographic features, specifically things like kerning, spacing. It’s got some advanced hyphenation capabilities, like it can actually do look-backs on your text to try and decide if something actually needs to be hyphenated or not, whereas with like an FO workflow to generate a PDF, it just lays things out in a line, so once it hyphenates something it stays hyphenated. You can also get some formatting in place that may be structurally difficult to automate in the PDF process, things like call-out boxes, sidebars, the application of special page formats. If you already have an InDesign workflow in place, you can maintain at least some of that existing workflow. And if you’ve got a lot of InDesign ability within your team, that’s probably a really good benefit.
JC: Now you need to weigh up, how much do you actually need each of these individual benefits? Which ones do you need to keep and which ones can you do without? These are the give and take that we were talking about earlier. How much of each side do you really need to keep in order to achieve your design goals? We’ve talked about what you need to consider organizationally when you want to get into this. Let’s take a look at the ingredients that actually go into the dish itself.
JC: Your content for this workflow is made up of three major components. You’ve got your DITA content, which is your main ingredient. It’s raw, maybe with a little bit of prep work done. Then you’ve got your DITA-OT transformation, which serves as a spice to help to accentuate the goodness that you’ve got in your raw ingredients. And then you’ve got your InDesign template, which is basically the serving dish. It helps bring everything together when it’s done, in a clean package for delivery.
JC: On the DITA side, again, it’s your raw content. This is the stuff that’s made by your content creators and subject matter experts. They aren’t really concerned what the content looks like. They’re primarily concerned with getting the content right and getting any metadata in there that’s necessary. And it also contains generally little in the way of formatting information. The most you’ll probably have is something like image dimensions, table layout information, maybe some basic formatting like bold or italic or something like that. When you’re looking at your DITA content, you’re going to need to run an audit on the InDesign content that you already have. Specifically, what kind of styles are used and why are they used? The why is the really important part, because that’s going to help you determine what’s going to be part of the post-transform process.
JC: One thing that I’ve noticed when working with clients with these workflows is that you really need to check and see if there are any manual adjustment styles. I usually see things like a paragraph style that’s specifically set up to prevent breaks or to insert breaks, in order to more cleanly control things like page count or other, to keep content together as necessary. Once you start looking in this, you’re going to find out that you likely need to specialize. Specialization can sometimes be a little spooky, but it’s fine. The important thing to realize here as to why you will probably need to specialize is that InDesign isn’t actually structured, but you’ve got reasons for applying a particular paragraph style or a particular page master. That actually can imply a structure. In order to be able to apply the various paragraph styles that you need in order to actually format your content, you’ll either need very detailed baseline DITA content or specialized DITA content in order to make that implied structure that you build out with paragraph styles explicit.
JC: Let’s just take a look real quick at a standard warning. Let’s say this is in InDesign. We got a warning here, says not to cut yourself when you’re preparing your vegetables. Looks like we’ve got it offset in a box so that it’s easy to see. We’ve got some colors on there to make it pop. We’ve got some paragraph styles that are used to make sure everything is aligned neatly with everything else, so that it really, really stands out. This is what it would probably look like in DITA, just a standard note element with a type attribute that says it’s a warning, with your text inside it.
JC: Let’s take a look now at a variation on that. Let’s say you need to have a little knife image in there, just to further call out, hey, be careful, knives are sharp. Or there’s some other sharp-thing-based danger still. In order to accommodate this knife image, we actually have to set this up differently. Either we need to set up that paragraph style to accommodate the space or have a specific object style for that knife image in order to make sure that that text wraps around it instead of over it. Still, we can put this in DITA, and this is probably what it would look like. It’s pretty much the same, except now we’ve got an image element in there that points to the knife.
JC: Still, this seems to be a pretty boilerplate warning. You might want to reuse that knife, and do you really want to be manually inserting this image in every note to make sure that you keep all of your content consistent? If you update that knife image in the future, it could potentially be a lot of work, depending on the size of your content base.
JC: Let’s look at another warning. This time we’ve got a different image in there. This time it’s about potential burns. The paragraph style, probably the same here, probably the same object style, but we’ve got a different graphic. Again, we could probably store that image in the note element, but if you need it repeatedly, you need to think about how you’re going to maintain it across all your content in the future.
JC: Now we’ve got three warnings with three different kinds of content, but we’re keeping this all within the standard DITA note element. There’s no actual semantic difference between them within your DITA content. So at this point, we actually do have an implicit structure that needs to be repeated. You should seriously consider specialization at this point, because if you have a lot of content, and across all of your content you have, say, 500 different sharp warning instances, it’s going to be difficult to have your content creators update all of them.
JC: Let’s take a look at a couple of specialized structures that could contain that burn warning. You might also need to specialize if it’s difficult to use the existing structure to contextually determine when you need to apply a style. We’ve got different paragraph styles that we could potentially use inside each of those warnings, so we would need to figure out how to say two are transformed. We need to apply this particular paragraph style here instead of the standard one that spans the entire cell.
JC: Let’s go ahead and take a look at the hazard statement. Hazard statement is a specialized element, but it’s part of out-of-the-box DITA, so you always have access to it. However, taking a look at it, does it actually fit your needs? The hazard statement element is generally used for industrial warnings, and as we can see, we’ve actually had to rewrite the warning in order to fit within the semantic structure. So does this actually convey the information that we want to, and is it worth it to go and try and rewrite your content in order to fit this?
JC: Or we can take a look here at a specialized note. The big change that we have here is that we have added a subtype attribute, which we can use to identify the image that goes with the warning. We have subtype “burn,” or say it’s subtype “sharp,” and that says which image is going to go in there, so that we don’t have to manually insert that image every time. And if we change that image, we only need to change it in the place that it’s being retrieved from. You don’t need to worry, am I updating all of the instances of this image throughout all of our content sets?
JC: When you’re looking at your content, you also need to get used to the idea that you are going to need to overload your content. Content creators are likely going to need to include a lot of additional metadata, especially if your InDesign content is sufficiently complicated to require that. And you really need to be sure to include all of it, or your content might not format properly. The transform process as it currently stands also can’t reliably strip sizing information from images, so you need to include the targeted dimensions for that in your DITA content, particularly if you have an image that you need to display at a different size than its actual native resolution.
JC: InDesign also requires a lot of information in order to format things like tables correctly. In order for those layouts to work, you’re going to want to use an actual table element rather than something like a simple table element, because using a full table element will allow you to use things that will let you define the full size of the table itself. The big takeaway from this is, even though it’s a lot of work to maintain and get in place, having all this information there is good, and these metadata attributes are your friend.
JC: Let’s go ahead and take a look at the Open Toolkit plugin side of things. The plugin contains a manifest of all of the styles in your InDesign template, your paragraph styles, your object styles, your character styles, your table styles, everything like that. The only thing is that it requires clear communication with the plugin architect as to what styles are there and how they’re used, because on the OT side of things, it’s just a manifest of what styles are there. It doesn’t actually contain any other formatting information. So you need to keep that line open and clear so that we can be sure to apply all the styles correctly in all the right places. Because of the fact that the content creators, plugin architects, and design team all need to work together to generate output, you need to be sure to get everything clear, because any miscommunications or design pivots can lead to a cascade of issues that can cause significant delays.
JC: Let’s just go ahead and take a look at a couple of different projects. We’ve got Project A, who has a well-defined set of specs, along with, say, a guide that talks about how styles are applied and how any specialized content they have is formatted. Whereas Project B has specs. They might not be up to date. Project A maintains clear open lines of communication with the plugin architect, whereas Project B, it’s not really clear lines of communication. Sometimes there’s some contradictions and things that require clarification.
JC: Project A’s template is very clean. It is organized with style groupings. They don’t have a lot of manual overrides in place in their end content. Whereas Project B, they have a large template with a lot of styles that may or may not be in use anymore, that may have been created by different people for different reasons. The end thing that we want to look at here is that yes, Project A, it’s a little pricey. But Project B, because of the delays, because of the need to constantly realign and make sure that all the formatting is correct and the degree of back and forth, it balloons the cost considerably.
JC: Let’s talk about the actual considerations for the transform. It’s easily the most fragile part of the process, especially if your content is very structurally complicated. When you talk to your plugin architect, you want to be sure that you have default values for image sizes or tables, so that you wind up with content that doesn’t wind up formatted weirdly or disappears from your output. Say for example you have an image that may be legacy content, doesn’t have dimensions on it. If you don’t have the dimensions in place, it won’t actually appear, but the transform will be able to say okay, this image doesn’t have any size information, but this is the most common image size, so we can actually slot that in there. That’ll let your content come out, and you can make adjustments later to bring that content in line with everything else.
JC: You also want to be sure that your plugin architect knows about any unique or uncommon elements, like learning specialization content or any other specialized content that you might have, in order to make sure that those elements have proper handling so that they get all of the styling applied that they need.
JC: And then on the InDesign side of things, this is your InDesign template that defines all of your styles, masters, and all of that visual formatting stuff. It’s important that all of this is codified and documented, especially about anything that’s been dealt with via manual overrides, so that we can be sure to help streamline and improve the template so that you don’t have to go in and do as much manual adjustment in the post-process. You can apply manual overrides after you’ve generated and placed your content, but the automated process through the transform can’t actually apply them for you.
JC: We’ve been over this already when we were talking about warnings, but it bears repeating. You need to have distinct styles for each distinct formatting variation. It’s especially important because your plugin architect needs to know, again, all the styles that are in your template in order to apply them. And in order to get the images to fall on the page in a reasonably close place to where you want them, you want to use object styles. They’re going to help define where things fall on the page. It’s also useful to have style groupings, just because once your list of styles gets to a certain number, it can become a little difficult to navigate.
JC: If you have multiple templates for defining things like different page masters for your body or different actual formatting on the styles themselves, you want to try and keep those names consistent between the templates. Have your body style called “body” in both of your templates. The reason you want to do that is because you can actually take your content and put them into either template, and as long as those styles are there, they get applied. And we’ll go over that in a little bit as we talk about the workflow overview.
JC: Now that we know what parts are involved in the process, we can take a quick look at the workflow itself. This is our standard PDF transform workflow. You take your DITA source, you package it up, you send it off to your plugin, which processes it, turns it into an XSL-FO file generally, and then runs that through an FO processor like Apache FOP or Antenna House, and that generates a PDF. As you can see, the styling is applied inside the black box of the transform.
JC: In the DITA-to-InDesign workflow, it’s a little similar. You take your DITA source, you package it up, and you run it through your plugin. The difference here is, the element mapping is applied at the transform, which generates an ICML file, which contains your content in a format that InDesign can understand. While it has the mapping of elements to styles, it doesn’t actually contain any style information itself. Then your design team takes that ICML file and flows it into your InDesign template, and the template actually applies the styles that are in the ICML file itself. It says “body” in ICML, but that actually doesn’t come into play until you put it inside a template. Once you’ve flowed that content into the template, your design team can finish the rest of the layout.
JC: Let’s go ahead and take a quick look at a demo. Let me just pop out real quick. We’ve got our InDesign template here. I’ve put this together. As you can see, we’ve got our character styles, our paragraph styles, all that stuff that we said we needed. Then in our output folder, right now we don’t have anything in our output folder, so I’m just going to transform on one of our white papers. You’ll actually see it’s flowing it out into our output folder as it processes everything. As you can see, we’ve got a common assets folder, our images, and a couple of ICML files. We’ll actually go into why there’s a couple of them there, in just a second.
JC: Now that we have our ICML files and our InDesign template, we’re going to hit Ctrl-D to bring up our placement window. We’re going to select our main ICML file, and that loads it into our cursor. We’re going to hold down shift to autoflow it and place it into our template. And as you can see, we’ve got our content here. It’s pretty straightforward, but you can see we’ve got level one headers, level two headers. We’ve got body text, we’ve got bullets, we’ve got character formatting. We’ve got images, and we’ve got character styles that change the color of things.
JC: But this doesn’t have the actual title of our document in it. This isn’t an executive summary, it’s a Scriptorium white paper. We actually have another page master up here that is our front page master. When the transform generator output, it actually generated a front cover ICML, which contains a separate story, which contains our front cover with all the formatting that it needs. We’re just going to load this in here, and now we have a complete white paper in InDesign that we can export, package up, or modify as necessary.
JC: Okay. All right. Now that we’ve seen how that works, let’s talk a little bit about how we can make changes to this. If we need to make a change to a style in InDesign, say body, we had things at Times New Roman, 10-point size, with 12-point leading. If we needed to change that, we don’t need to do anything in the transform itself. We just need to make that change in InDesign, and as long as we don’t do anything like changing the style name or moving where it is in the template by putting it in a different style grouping, for example, everything should work just the same.
JC: Now, if we need to actually change what style is applied, or you do go ahead and change the name or put it in a different style grouping, that’s a little bit different. At that point, the design team needs to make the change, communicate that change to the plugin architect, who then goes into the plugin, makes the changes to ensure that that new mapping is applied, then that gets fed out into the ICML output, which then gets flowed into the InDesign template.
JC: So that’s our primary difference. It’s when and who handle your changes. In the PDF workflow, you need to relay new design specifications to the plugin architect, who has to encode it all into the plugin every time. If you need to make changes to your template, the InDesign team can handle that entirely dependently, again, with the only exception being that if you need to apply new or different styles to your content, you still need to go to that plugin architect, so that it gets to make its way into the ICML output file.
JC: But, however, because styles aren’t the only thing that can change, if your InDesign team edits their content, like say you need to update something that was legally required but you don’t have time to run the entire layout process again or run your content through an entire workflow in order to get approval and everything, just something that’s one-off you need really, really badly, you need to be assured that your InDesign team gets that content change information back to the DITA team so that your content is consistent, because you never want your final output to be more up to date than your source content, because then you need to be sure where the correct content is. Is it this output file that isn’t going to be flowed back into your main content store?
JC: Yeah, this sounds like a lot, and it is, so this is the point where you need to ask yourself, is it worth it? What would make this worth it? Just to get back into what we were talking about earlier about high-design, the things that make this worth it is, is your content your actual product? I’d imagine that companies that make textbooks value the layout and format of their content much more highly than somebody who’s putting together very rote, straightforward torque information for drill manuals. Maybe you’re transitioning over to DITA and you have a team that needs to be able to leverage the modular content within InDesign.
JC: Say you have your tech pubs team moving into DITA and getting all their content put together there, but your marketing team wants to utilize some of that technical content in their high-design environment. This might actually be a long-term solution for you, or something that could fill the gap over a multiyear transition period as you move everybody over to DITA. Your content formatting requirements may be a little bit much and a little complicated for an automated workflow to handle. Restrictions that might be regulatory in nature, like style guide requirements for legally sensitive material, or you have specific print requirements that you need to be sure something fits into that an automated workflow might not hit 100% of the time.
JC: I reached out to someone a while ago who actually runs our DITA-InDesign transform to see why this solution works for them. They have a lot of variation in their content, enough that they would actually need to have multiple PDF transforms, which could be cumbersome and difficult to maintain over a longer period of time. And they also have complex content formatting needs that require them to manually adjust pages for one-off layout solutions. And the core of it is that DITA-to-InDesign gave them the ability to use as many templates as they like and have the ability to adjust the output as they needed. It was a good solution for them. Is it for you? It might. For further reference, I did a podcast with Gretyl Kinsey a while back to talk about high-design content. Both Sarah O’Keefe and myself have written a few blog posts on working with DITA and InDesign. I’d like to go ahead and open us up for questions.
EP: All right. Thanks, Jake. I have a couple questions that I am going to go ahead and start with. If you have any have come up during this presentation, then please feel free to go ahead and drop those into the questions module now. One comment that someone made was that they would be especially interested in populating and styling tables. So could you talk a little bit more about that?
JC: Okay. Dealing with tables actually isn’t too different from what we saw earlier when we were looking at that sample note element. Basically, you just need to ensure that your table is encoded properly in DITA and either you have all of your dimensional information in it or you have fallback information for standard table sizes. The InDesign transform, when it’s actually going through that transform process, will take a look at that table, determine either via what element it is or what elements are around it what table style should be applied to it, and then apply that, as well as any individual cell styles. The key is to have all of your table formatting information in InDesign in your table and cell styles, and then make sure that all of that gets mapped properly across in the transform itself.
EP: Great. Another question just came through, is the ICML spec public?
JC: Yes, the ICML specification is public, although in making my way through it, I have found that it doesn’t answer all of my questions, if that makes sense.
EP: Okay. Another question, do you use a bookmap to assemble different topics?
JC: That actually depends on your needs. Like any DITA Open Toolkit transform, it will take any input that it is expecting. As a baseline, it can accept single topics, it can accept standard ditamap files, or it can accept bookmap files. The decision for which one to use depends on how much information you actually need in your metadata in order to create that rich content that you’re looking for. So for example, if you’re putting together, say, just a single datasheet, then you may not need to package that into a map. You may be able to contain all of the metadata that you need and all of the core information that you need in your topic, just within a single file. But if you need something like a main book title, subtitle, things like that, you might want to look at the more fully-featured bookmap so that you can get all of those things in place.
EP: Great. And we have one question that came through in the registration, and then also one that came through right now, and they’re very similar, so I’m just going to ask one of them, and then if there’s any follow-up from the attendees, please feel free to drop that into the questions module. Can images be auto-imported from a library with a processing instruction, and can these images be automatically sized to fit text block dimensions?
JC: I know that it is possible to do things like have a master page that effectively acts like a reference master in something like FrameMaker. And since you’re working inside InDesign, you actually have access to running scripts on your file. We’ve actually developed some ExtendScripts to do things like creating active hyperlinks and inserting them into InDesign’s internal library for publication. So yes, it is possible to have those things identified and use ExtendScript to locate them and insert them into anchor points that the InDesign transform can create.
EP: All right, great. Thank you. Another question, is the transform discussed the transform that ships with the OT?
JC: No, this is actually an internal plugin that Scriptorium has created, and we have actually customized for several different clients.
EP: Great. Thank you so much. I’m not seeing any more questions now, so I’m going to give you all just a couple more minutes here to drop any final questions into the module. I did go ahead and drop the link to our evaluation survey in the chat box, so if you could take a minute to fill that out for us, we would really appreciate it. If you think of any questions after we end the webcast today, feel free to send them to [email protected]. Also, if you have anything that’s just a little more specific than what we went into during the webcast today, you can also send those questions to [email protected]. Just one second. I see a couple more questions that came through. Is there a max number of pages in a document?
JC: That is completely dependent on InDesign. If InDesign has a maximum number of pages, I assume that that number would be dependent on the amount of memory that your machine has, but that is on InDesign.
EP: Okay. And then another one, are all of your solutions custom, or are there any off-the-shelf products to get started?
JC: I know that there are some vendors that do offer licensed solutions, and I do know that there is… I believe, yeah, Elliot Kimber, I think, has a DITA for Publishers plugin for InDesign. But I’m not very deeply familiar with any of those solutions.
EP: Okay. And then there’s one more here. Will an image file size crash the composer?
JC: Ooh, okay. I’ve been working on our InDesign transform for a few years now, and InDesign is more stable now than it was, say, four or five years ago. One of the biggest hurdles that I ran into was when I was testing to make sure that content flowed in correctly. InDesign would just occasionally silently crash and not deliver an error message. So it is possible that there may not be error handling on something and it might cause a crash, but I would think that if an image is causing InDesign to crash, it may be memory related, something that’s hardware, not software related.
EP: All right, great. All right, I’m going to give you all just another second here for any additional questions. I just included the email address, if you have any additional questions, in the chat box in our chat module. And I’m also dropping in our Twitter handle, so feel free to follow us on Twitter for any additional webcasts that we have coming up, content that we release on our website. We publish all of that there. I’m not seeing any more questions at this time, so I think we are going to go ahead and wrap up this webcast. Thank you so much, Jake.
JC: Yeah, and thanks to everybody for listening to me talk for a while.
EP: And if you all, again, any more questions, feel free to email us at [email protected]. And have a wonderful rest of your day.
About the author
