multiple localized CSSs > single PDF

pdenchfield · Post by **pdenchfield** » Thu Jun 19, 2014 10:40 am

Looking for expertise from anyone who creates multiple-language PDFs.

We use global project linking, importing each localized Flare project with folders and variables uniquely identified by language, and inserting each of 13 localized .fltoc files into the global .fltoc file. Everything looks great, EXCEPT for the CSS-driven content: "on page" xref phrases and "Figure" and "Table" labels appear in English throughout the PDF.

We tried setting the target (*.fltar file) to "default" for the stylesheet and rebuilding, but it still uses one CSS file for all content.

How can I make the PDF output use localized CSS files per inserted .fltoc file?

Msquared · Post by **Msquared** » Thu Jun 19, 2014 12:51 pm

This isn't a very good answer, I'm afraid, but it's the best I can do.

The default Stylesheet that will be picked up if you specify that for a target will be your project default, which is probably your English one. So that's why that didn't work

Leave the default Stylesheet as English, and set the stylesheet individually for each localised topic to the localised Stylesheet for that language. You may be able to do it for multiple files using the File List view, I'm not on my PC right now to check.

It's fiddly, I know, and it also means that if you add a topic, you need to remember to set the correct Stylesheet for each translated topic too.

This may be worth a feature request. I can imagine that others may need to create a single PDF with multiple languages.

pdenchfield · Post by **pdenchfield** » Thu Jun 19, 2014 1:22 pm

Thanks, Marjorie! I will set up a test project to try this out.

Msquared · Post by **Msquared** » Fri Jun 20, 2014 12:58 am

Forget that - I don't think it will work. I do have a crumb of hope at the end of this post though.

You can view the stylesheet that's set for an individual topic, either in the topic properties, or for many topics using the File List view. But you can't set it - at least I can't as it is greyed out.

You can manually set a stylesheet for a topic in the XML, in the <head> section, like so:

<link href="../../Resources/Stylesheets/GLOBAL Exony Print Styles.css" rel="stylesheet" />

In fact, Flare does this when it imports from Word and you tell it to use an existing stylesheet. But Flare doesn't seem to use this stylesheet setting. I usually delete all of these on import immediately as part of my post-import tidying up, but I have a few that have slipped through the net. In each case, the stylesheet specified for the topic is overridden by the stylesheet specified for the target.

So that's what looks like it could work, and doesn't.

But I notice that you can add a TOC entry that is a whole Flare project and target. So if each of your translated sources was in a separate project (or perhaps even a separate target in the same project) you could try adding that to the TOC where you wanted the content for that language. Then you can set a different stylesheet for each target.

Good luck. Let us know how you get on.

pdenchfield · Post by **pdenchfield** » Fri Jun 20, 2014 8:02 am

Msquared wrote:But I notice that you can add a TOC entry that is a whole Flare project and target. So if each of your translated sources was in a separate project (or perhaps even a separate target in the same project) you could try adding that to the TOC where you wanted the content for that language. Then you can set a different stylesheet for each target.

Almost right - I have a single target for all translated sources. I add a TOC entry for each translated source's .fltoc file, inserted into the main .fltoc file in the global project.

Perhaps the best workaround at this point is to insert the stylesheet reference in the head section of the xml as you suggest. It does seem tedious! I'll do some testing and post back...

ChoccieMuffin · Post by **ChoccieMuffin** » Fri Jun 20, 2014 8:23 am

Is it a silly suggestion to create separate language projects and merge the PDFs manually afterwards?

pdenchfield · Post by **pdenchfield** » Fri Jun 20, 2014 8:58 am

Hi Chocciemuffin, you're right - if we wanted unique page number ranges per language, separately produced PDFs (separate targets) per language would be the easiest approach!

However, we want a continuous range of page numbers, such that the main TOC can list each localized name of the guide with its associated page number.

Msquared · Post by **Msquared** » Fri Jun 20, 2014 9:56 am

Perhaps the best workaround at this point is to insert the stylesheet reference in the head section of the xml as you suggest. It does seem tedious! I'll do some testing and post back...

I tried that this morning, and I couldn't get it to work. A stylesheet set at topic level seems to get completely ignored.

That's why I suggested splitting each translation up into a separate TARGET, but all contained in the same project. That way, you could set the translation-specific stylesheet for that target, then build one grand TOC linking to each of the targets. Then hopefully, the stylesheet you have specified for your grand TOC will apply unless it is overridden by one of the target stylesheets. I think that could work.

As far as I can see, this is the same as having a master TOC that contains sub-TOCs, which I already do, but by wrapping that TOC in a target, you get the ability to set all the things you could set at the target level for that TOC, which is where you're falling down at present.

I work Choccie Muffin's way, and have a separate project for each translation, but that's because we don't need to ship them as a single item, but separately. I can imagine situations where that's not what is required.

pdenchfield · Post by **pdenchfield** » Fri Jun 20, 2014 10:46 am

Hmm, we may have to rethink our output if Flare does not allow us to use multiple CSSs within the same target.

Msquared · Post by **Msquared** » Fri Jun 20, 2014 11:10 am

That's why I'm suggesting you try making each language a separate target. You don't have to build each target separately - you will still build just your combined target. Just think of it as a container for the TOC that contains the content for that language. And it's a useful container, because you can set the stylesheet property for it, AND you can include it in your main TOC. I think that's the way to go in your case.

pdenchfield · Post by **pdenchfield** » Fri Jun 20, 2014 11:22 am

Marjorie, are you referring to the TOC entry properties dialog box option for "Select Flare Project and Target... (for runtime merging)" as shown in red outline in the screenshot below? I'll have to try that!

toc-flareprojtarget.png

Msquared · Post by **Msquared** » Fri Jun 20, 2014 11:29 am

Yep, that's the one! I've not tried it myself, but it looks extremely hopeful for your situation.

I already include other TOCs in my main TOC - I think this will effectively be the same, but with more (useful!) properties that you can set on each target.

If you don't already have separate sub-TOCs for each language, and need to make them from your main TOC, then here's a tip. The TOC window supports cut and paste using Ctrl+C and Ctrl+V. So you can just make a new empty TOC, then select the TOC books and topics you want to put in the new TOC, and cut and paste them directly from the main TOC. No need to recreate each one manually, or hack around in the XML to do it.

pdenchfield · Post by **pdenchfield** » Fri Jun 20, 2014 11:38 am

Looking forward to testing this! Thank you, Marjorie.

techwriter31 · Post by **techwriter31** » Fri Jun 20, 2014 3:59 pm

Just curious - but in the Project Properties dialog, is the English stylesheet specified as the Master Stylesheet? If so this would would override also the stylesheet setting in the target file. Also, if the stylesheet is set in either the Project Properties or any target that references these topics, this will disable the stylesheet option when applying to individual topics.

But I agree that if you can do runtime merging, that would be ideal. For some reason, I thought this wasn't supported for PDFs, but it's been a while since I've tried it.

Msquared · Post by **Msquared** » Sun Jun 22, 2014 12:46 am

Interesting, Kellie. I didn't know that. So what you're saying is that topic-level stylesheets are overridden by the target-level one, to the extent that if you gave a target-level stylesheet specified, Flare doesn't even allow you to set a topic-level one. If you already have one set, it is ignored.

That's back-to-front from what would normally happen, where topic level settings overwrite the target-level defaults.

If that's the case, then it explains what I was seeing, and does mean that Pamela does have another option for topic-specific stylesheets. I'd still be tempted to go with the sub-targets approach, one for each language, if that works, since then once you have added a new topic into the appropriate language target, it will get the correct stylesheet automatically, without needing to remember to do a separate step to set it.

pdenchfield · Post by **pdenchfield** » Mon Jun 23, 2014 8:23 am

Looks like runtime merging of projects is not supported for PDF outputs.

runtimeimport-pdf-notsupported.png

Msquared · Post by **Msquared** » Mon Jun 23, 2014 10:42 am

I'd check with support.

Interestingly, I'm in the act of debugging the 40038 error message too. In my case, I've been building PDFs for weeks - all I did was renamed about 20 of my topic files at the request of our developers - they want to be able to display the contents directly from the application and outside of the Flare-generated WebHelp in some cases and need a consistent naming convention so they know what files they need to use.

Doing that caused the error 40038 message for just two of my renamed files. I reinstated one to the old name, and it built fine. The names are not too long, nor do they use any odd characters. I wonder what is going on. I don't use linked targets, but I do use linked TOCs. I wonder . . .

Mine is a separate problem, but I'd check yours with support anyway. I'm suspicious that there is something else going on, for both you and me . . .

pdenchfield · Post by **pdenchfield** » Mon Jun 23, 2014 2:30 pm

Case 63050 filed with Madcap for lack of PDF support for runtime merging of Flare projects and their targets. Thanks!

pdenchfield · Post by **pdenchfield** » Mon Jun 23, 2014 2:51 pm

Tech support confirms that runtime merging is not supported for PDF output. Response below.

As of now, runtime merging is only available for online outputs. I have included a link to our WebHelp, which explains more about Runtime Merging. I have also this as a feature request on your behalf to our Product Managers who work with our Research and Development team regarding future versions of our products. If this feature is implemented in a future version of Flare, you will be notified via e-mail, referencing report number 69148.

http://webhelp.madcapsoftware.com/flare ... ojects.htm

Msquared · Post by **Msquared** » Mon Jun 23, 2014 10:58 pm

Oh, so it's plan B with thanks to Kellie, I think.

If I understand correctly, what you need to do is set the target stylesheet to nothing, probably by choosing (as is) or something like that. Then you should be able to set stylesheets for each topic.

pdenchfield · Post by **pdenchfield** » Tue Jun 24, 2014 10:28 am

Update: Per tech support, there are two places to check if stylesheet is grayed out for topic properties:
* project properties > make sure Master Stylesheet is set to "default"
* (primary) target > make sure Master Stylesheet is set to "default"

I updated my project properties and was then able to easily update topic properties for sets of topics to the stylesheet. One problem solved!

NEW ISSUE OCCURRED, HOWEVER. Now the PDFs I generate are strangely styled. I think it might have something to do with the mc-heading-level values. Even though paragraphs are tagged as h1 (which is mc-heading-level of 2) and the target is set to use TOC depth, some headings take on the appearance of style tags that are mc-heading-level of 1 (p.ChapterCounter, for example). Any ideas?

topiccss-before.png

topiccss-after.png

pdenchfield · Post by **pdenchfield** » Tue Jun 24, 2014 11:52 am

Has anyone discovered how to configure PDF builds to derive English phrases â€œChapter,â€ â€œFigure,â€ â€œTable,â€ and â€œon pageâ€ from a source other than the stylesheet?

If this move is possible, then I can continue setting the stylesheet at the project or target level and avoid this new styling issue that arises when I set the stylesheet at the topic level.

Msquared · Post by **Msquared** » Wed Jun 25, 2014 4:21 am

I'd be very surprised if we can't get to the bottom of the styling issue.

Firstly, when does it happen? Try and see if you can find the common factor. Is it for all topics that use a particular stylesheet, but only that stylesheet? For some topics, regardless of the stylesheet they use? For some heading styles, regardless of the topic and/or stylesheet? For some structures in your content, and not for others?

Once you've isolated when the problem occurs, you should know whether you are looking for a problem in some topics, or in some of the localised stylesheets, or in some of the style definitions. Since it works for some stylesheet/topic combinations, it should be quite easy to track down the problem as you will have examples that always work, and examples that always don't for comparison.

If you aren't into solving logic puzzles (I love it, but not everyone does, I know!), then I'd call support - I'm sure they'll help get to the bottom of it.

pdenchfield · Post by **pdenchfield** » Wed Jun 25, 2014 9:51 am

Thanks, Marjorie! Tech support identified the issue as mc-heading-level values applied to non-heading styles (p.ChapterCounter) and being off by one in the heading styles (such as h1 mc-heading-level set to 2). It appears that I need a separate stylesheet for PDF outputs that include multiple languages (aka combo guides), as these don't use the p.ChapterCounter, so a different mc-heading-level structure is needed. I now have successfully generated PDFs using each stylesheet: combo and chapter.

At some point I'd like to find a way to better manage these stylesheet variations, but for now, all's good!

MadCap Software Forums

multiple localized CSSs > single PDF

multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF

Re: multiple localized CSSs > single PDF