-
1. Re: initial caps in H/F variables
Error7103 Oct 1, 2013 9:09 AM (in response to FieryPantone)> ... asking for the header style where I use H/F1 to be all caps.
Can you apply, to the MasterPage H/F para instances,
a Character Format named, say, "Uppercase" that has only
[*] Uppercase
elected?
For other hacks, you may now be able to use <$Uppercase> as a building block where Character Format BBs are allowed.
You could also apply [*] Uppercase in the para format for the header, but there are usually other elements that you don't want to do that to.
-
2. Re: initial caps in H/F variables
FieryPantone Oct 2, 2013 2:10 AM (in response to Error7103)Terrible admission, but I fear I may not have explained myself clearly! I like the idea of using a character style building-block, though, and shall save it for later.
Now to try again with a better explanation …
In the body text, the chapter heading is capitalised like this: Chapter heading
If the paragraph style for the running head specifies all caps, the result is (logically and correctly) CHAPTER HEADING
Because I don't like mixed-size caps, I would like the running head to show CHAPTER HEADING, as though the body text were chapter heading with no initial cap
-
3. Re: initial caps in H/F variables
Error7103 Oct 2, 2013 4:29 AM (in response to FieryPantone)Other contributors here may have a more elegant solution, but I can think of any number of hacks, such as ...
At each Heading1 instance, create an anchored frame, at insertion point, with a text frame inside it.
In that text frame put a paragraph of format Heading1.RHF, which is an invisible text color (white-on-white works, as does using a font color set to Invisible by Color Views). Heading1.RHF could also employ a tiny point size so it won't cause wrap-around or other flow issues. Hand-duplicate the normal Heading1 text in all caps - you might as well just type it that way, rather than apply a format.
Set system variable Running H/F 1 to <$paratext[Heading1.RHF]>.
This (and other hacks I can think of) require duplicate headings.
-
4. Re: initial caps in H/F variables
FieryPantone Oct 4, 2013 12:45 AM (in response to Error7103)Aha! bouncing ideas around is where forums can really help.
Thanks for your taking the time to think up and describe the solution you offered. Something about it got me thinking, and I came up with the following alternative …
- set the actual chapter title (using style :h1) in lower case: aardvarks and their habitat
- set H/F1 as <$paratext[:h1]>
- set the paragraph style for the header that picks up H/F1 to use small caps and obediently display AARDVARKS AND THEIR HABITAT
- scandalise typographers by applying a !smallCaps character style (a few points bigger) to the first letter of the :h1 and get Aardvarks and their habitat
- oh, and check that :h1 and :h1ToC style use the same character size
The mental gymnastics FM occasionally encourages must be good for our health :-}
-
5. Re: initial caps in H/F variables
Error7103 Oct 4, 2013 7:20 AM (in response to FieryPantone)> The mental gymnastics FM occasionally encourages must be good for our health :-}
Yes, but think of the poor document steward who has to maintain the stuff after you retire.
That dismay may be offset by visions of post-retirement consulting fees.
-
6. Re: initial caps in H/F variables
peter at knowhowpro Oct 4, 2013 8:35 AM (in response to Error7103)I've stood idly by long enough<G>.
InDesign has a feature called Nested Styles. It applies named character styles (formats) within a paragraph, by obeying rules that you specify. A rule can apply a named style, or none, up to, or through, a specified number of words, characters, special characters, or non-printing characters. Then it obeys the next rule, and applies whatever, up to or through whatever, and so on. There's also a rule to repeat the last N-number of commands.
If FrameMaker had nested styles, you might be able to use it for the mixed case headers. There's no way to test it, since it doesn't exist in FrameMaker.
Here's the Catch-22: InDesign's text variables are treated as a single character - they can't wrap across line endings, and their width is fixed to the width of the text frame that contains them, so long headers can't wrap, and variables in body text can't wrap, either.
"I want what you've got." "No, I want what you've got." etc.
InDesign also has GREP paragraph stye properties that apply named character styles within the paragraph to content that matches the GREP pattern. And InDesign also has line paragraph styles - you can specify that line N within a paragraph gets a names character style; when the paragraph reflows, the N-th line's nested style does the Vegas thing - it stays in the line it's assigned to.
There's always the feature request form, eh?
Regards,
Peter
_______________________
Peter Gold
KnowHow ProServices
-
7. Re: initial caps in H/F variables
Arnis Gubins Oct 4, 2013 8:58 AM (in response to FieryPantone)Niels,
It might be a lot easier if you used the running h/f markers instead of multiple paratags. Put the desired header content in the marker (actually, just have the content of the heading tag selected and then open the marker dialog to populate it) and apply the correct case in the marker. Then use the <$marker1>, etc. (Running H/F 3) variables in the headers on the master pages instead of the <$paratext building blocks). You can apply a character tag to the running header/footer variable for formntting changes that may vary from the entire header paratag.
You can then continue to use the :h1 for your TOC without excessive tag pollution (e.g. creating the :h1ToC tags) in your documents/template.
-
8. Re: initial caps in H/F variables
FieryPantone Oct 7, 2013 11:33 PM (in response to Arnis Gubins)Arnis – interesting! this whole question of markers is very new to me; in fact, the first time I ever came across a reference to H/F3 was when trying to post a helpful answer to a question a couple of weeks ago. Something I need to read up on.
As for tag pollution, I'm not sure I follow you: I had the impression that FM just created a ToC style for each body style it was told to pull into the ToC. Good thing too, otherwise you'd have to choose between (say) 48pt bold entries in the ToC or rather discreet 11pt bold for chapter headings. Proliferation of tags in my docs is more or less under control, as I have one master document with my own BookMaster-derived style-set. On quiet days, after sorting e-mails and deleting .backup files, I sometimes remember to remove all styles from troublesome documents and use f,u,a to clean them up <g>
-
9. Re: initial caps in H/F variables
Arnis Gubins Oct 8, 2013 7:43 AM (in response to FieryPantone)Niels,
I may have misunderstood what you were doing. It appeared to me that you had an additional :h1ToC style for the alternate entry that would have been used for the TOC also, as FM adds a "TOC" (all upper-case) to the existing tagname when creating the actual TOC entries.
The Header/Footer markers (there are 8 of them available now) are very useful and you can reset them (i.e. just enter an empty marker) on a page to ensure that content doesn't spill-over to the following pages.
-
10. Re: initial caps in H/F variables
FieryPantone Oct 8, 2013 11:26 PM (in response to Arnis Gubins)The next quiet moment that comes along, I'll read up on Header/Footer markers – promise! they sound, indeed, useful.



