This is the history file for the last revisions for Mif2Go package 33. Rev 52, November 11, 2008 -------------------------------------------------------------------------------------------------------------------------------------------- The major enhancement for 52 is a new logging facility. We're still working on it, but you'll notice a mif2go.txt file appearing in the output directory that lists "events" during conversion. It works for RTF, HTML, XML, and DCL outputs, and also includes events from the plugin after a project has been selected. These settings control it: [Logging] ; Log entries are appended to the log file, and consist of: ; timestamp (if different from last one), on its own line ; type (E, W, Q, I, D) ; severity level (1-9) ; description with identifying details ; Example: ; W2: Xref target ag123456 not found in somefile.ref ; ; UseLog = Yes (default, log as specified in this section) or No UseLog=Yes ; LogFileName = name with path, absolute or relative to output dir LogFileName=m2g_log.txt ; These take severity values, 1 (worst) to 9, or 0 to prevent logging ; LogErrors = 1 (default, log events that terminate process) LogErrors=1 ; LogWarnings = 1 (default, log problems with workarounds that may ; result in undesired output) LogWarnings=1 ; LogQuerys = 1 (default, log possible ambiguities) LogQuerys=1 ; LogInfo = 1 (default, log process information) LogInfo=1 ; LogDebug = 0 (default, don't log possible programming issues) LogDebug=0 **For HTML (build h285), Seraphim Larsen was back at it only two days after our release of 51, finding that our ditavars.dita file for Frame variables, and our ditamap (or bookmap) file for the full book, did not respect his specializations of the DOCTYPE ids like all the rest. In addition, the full-book map file didn't notice the XHLanguage setting, retaining the default "en", and the ditavars file missed the xml:lang attribute altogether. We've fixed all these oversights. He also discovered that when a stripped figure table followed a normal table, the ID of the preceding normal table was incorrectly used in the href intended to reference the figure in an . That's fixed too. Never satisfied, he then wanted to get a title into the chapter ditamap without having to specify it in a marker or in the .ini; he wanted to get it from the title of the first topic, which was already used as the final default navtitle in the book ditamap's topicref for that chapter map. We added: [DITAOptions] ; UseAltMapTitle = No (default) or Yes (if no title specified for map, ; use the navtitle of the first topic in the file as the map title) UseAltMapTitle=No Seraphim also reported that the type attribute on xrefs was not always correct; sometimes it was "table" rather than the specific element in the table, like "fn" or "li". And sometimes conditions assigned to a table persisted to the next table. We've fixed those bugs. Then he pointed out that the ... unusual ... way DITA handles footnotes results in footnotes not getting callouts when they have IDs, unless an xref is added to provide the callout. We added those xrefs for him... but that wasn't enough. With further testing, he found the DITA-OT was inconsistent on this point. The HTML transfer wanted the xref, but the pdf2 transform did not. So we added this ugly kludge: [DITAOptions] ; FootnoteXref = Yes (default, comply with spec) or No (indulge bug in ; DITA-OT for pdf2 output using Idiom/RenderX by omitting footnote xref) FootnoteXref=Yes Next, he noticed that a footnote in a table title was incorrectly assigned the same ID as the table itself. We fixed that. Most recently, he reported that some of his xrefs were missing an open quote for the href attribute. It turned out that if a line-end was put in before it, rather than a space, the recorded position in the .ref file was off by one. That's fixed now, by forcing a line-end before each href. Julie Bruce needed to place an insertion at the very end of the , and the [Inserts]Head put it after the title. We added [Inserts]HeadEnd for this purpose, and implemented the related FirstHeadEnd, LastHeadEnd, SplitHeadEnd, and ExtrHeadEnd variants too. Yamini Moghe reported that when a GraphReplaceMacro is used, a graphic is not generated by the plugin. That was by design, but we now realize that the graphic should also be produced when it is referenced in such a macro. We now generate it whenever any of the [Graph*Macros] refer to it with <$$_graphsrc> or with <$$_graphbase>. The name need not appear in the output; a reference like <$$unused = $$_graphsrc>, which adds nothing, is sufficient to trigger graphic generation. Mark Dempsey reported that an unencoded "&" appeared in an index-file attribute. We were having a problem with double-encoded entities like &lt; instead of <, and the fix for that opened up a hole, which we believe is now closed. Jim Owens needed a file for his HTML Help project containing a list of the context-sensitive help IDs used, with the title (not filename) of the topics in which each were found. We added that option: [MSHtmlHelpOptions] ; AliasTitle = No (default) or Yes (generate .hht file with titles for all ; topics containing CSH aliases, like the .hha but with titles not filenames) AliasTitle=No Gershon Joseph found two problems in his DITA output that affected all HTML/XML formats. First, a URL in an href attribute contained an ampersand that was not properly escaped as &. Second, a variable in a paragraph marked for deletion in [HTMLStyles] appeared anyway if it was a conref or an entity reference. We fixed both of these bugs. Next he reported that some graphics, especially in table cells, had gone missing. We traced this to their positioning relative to page, frame, or column, which was taken as meaning they were not a part of the text flow. Although this could be true for some images used as decoration on the page, it wouldn't be for those in tables. We've now removed that conditional test, so that all graphics are included unless deleted specifically (or conditioned out). He also noted that we lacked a way of explicitly setting parents for images, the way we do for text. This led to interpolation of parent elements that were valid but inappropriate within and around s and s. We noticed that the same issue could come up with tables, so we added: [DITAOptions] ; ImageParents = parents for tags, whether wrapped in or not; ; default none (use content model), may include sets from [DITAElementSets]. ImageParents= ; TableParents = parents for table tags, including simpletable and others; ; default none (use content model), may include sets from [DITAElementSets]. TableParents= [DITATableParents] ; table ID (not type) = parents to be used for root table element [DITAImageParents] ; image ID (may be group) = parents to be used for image/figure element The latter two sections can also be used in HTMLConfig markers to set parentage for the following table or graphic. For this reason, we did not add specific marker types for this purpose; they'd be redundant. In addition, one of Gershon's many test cases showed us that often the automatic process that rearranged images and their titles and wrapped both in a fig wound up including more following elements, which was valid but unwanted. To handle this, we added: [DITAOptions] ; CloseFigAfterImage = Yes (default) or No (leave fig open for more) CloseFigAfterImage=Yes ; MultiImageFigures = Yes (default) or No (allow only one image in a fig) MultiImageFigures=Yes Gershon went on to complain that two elements, each in a stripped table, were not merged under a single parent. To allow this, we added: [Tables] ; CloseStrippedTables = Yes (default) or No (allow elements started ; in stripped tables to remain open until closed for other reasons) CloseStrippedTables=Yes Then he came up with a case where two images followed by the title for the second one both got packaged together in one fig. So that he could specify that the first was not to be put in the fig, we added: [HTMLStyles] ; NoFig is used in DITA for a graphic anchor para to prevent wrapping ; of the image inside it in a fig tag. Of course, this works only if the Frame format is used consistently for images that should not be wrapped, and not for any that *should* be wrapped. Imran Malek had a problem with graphics scaling not being handled correctly when a DITA output file was re-imported to FrameMaker 8. It turns out that FM8 assumes that image width and height attributes are in points (72/in) rather than pixels (96/in). The DITA 1.0 spec was not specific about the units used, but the 1.1 spec corrected this oversight and specified pixels as the default, providing a set of suffixes (including "px" and "pt") to make the units explicit. FM8 ignores the suffix, though. So we added a setting to force the sizes to points, and label them so that they remain correct for 1.1: [Graphics] ; This is effective for DITA only: ; UsePtSuffix = No (default, unless [DITAOptions]FM8Import=Yes), ; or Yes (FM8Import default, set ConversionDPI to 72 so that FM8 ; interprets the size correctly, and include "pt" in the width and ; height attributes to specify that the values are in points) UsePtSuffix=No Robert Lauriston informed us that since developers at his company create plugin.xml for Eclipse Help, he needed a way to exclude it from his own production workflow. We added: [EclipseHelpOptions] ; UsePlugin = Yes (default), or No (never write plugin.xml, use if ; not part of the deliverable system because others provide it) UsePlugin=Yes He also discovered that EclipseLink markers caused an exception during processing; we fixed this new bug. Esar Rudnikoff was generating file names from headings, and wanted to retain the underscores and spaces in those headings. While we consider this a Bad Idea for several reasons, as explained in the User's Guide, we do offer "more than enough rope", so we added: [HTMLOptions] ; When UseRawName=No, allow underscores and spaces to be passed through from ; headings with the FileName property as follows: ; KeepFileNameUnderscores = No (default, remove underscores) or Yes KeepFileNameUnderscores=No ; KeepFileNameSpaces = No (default, remove spaces) or Yes KeepFileNameSpaces=No Izzie Littman was surprised when his DITA output file was invalidated because of a closing tag mismatch. It was worse than that; a part of the file was shifted into the wrong place. We fixed that bug. Robb Surridge reported that when his project was run with no existing .ref files, some forward links were not fixed up to reference the right split file when the later file was run. He narrowed it down to links for which NoRef was set to eliminate the hash part of the link. With that clue from him, we were finally able to fix this bug. David Spreadbury wanted SmartSplits to keep together three heads at the top of a file, but it was splitting after the second one. This happened because there was a tiny para in between that was not a head, and reset SmartSplits. We added a setting to ignore such paras: [HTMLStyles] ; NoSplit prevents the para format from interfering with SmartSplit ; when it occurs in between heads that would otherwise be kept together. thinline=NoSplit He also was using heading text to set filenames for topics, and needed the spaces in the text replaced with underscores for the filenames. To do that, we modified one setting and added two more: [HTMLOptions] ; KeepFileNameSpaces = No (default, remove or change spaces) or Yes (keep) KeepFileNameSpaces=No ; ChangeFileNameSpaces = No (default; if not kept above, remove) or ; Yes (if not kept above, replace with the FileNameSpaceChar, below) ChangeFileNameSpaces=No ; FileNameSpaceChar = character with which to replace spaces, default '_', ; used if both KeepFileNameSpaces=No and ChangeFileNameSpaces=Yes FileNameSpaceChar=_ Gudrun Rahn told us that when index entries contained special characters that were represented in HTML as numeric character entities, the ending semicolon of the entity was being interpreted as an index entry break separator, like a normal semicolon. We've fixed this error. Aryeh Sanders encountered two bugs. In DITA output, the values of the colname and colnum attributes were swapped in s if you defined a ContentModel. And in any HTML/XML output, if the text assigned to an Object Property such as alt text for an anchored frame exceeds 214 characters, only the last under-214 section was included. We've fixed both these bugs. Then he found three more, all for DITA only. The ugliest resulted from a fix we made in the last update for graphics and tables that precede the Frame Below (if any) of their anchoring para; this did not play nicely with some DITA-specific code, so we've restored the previous functionality for DITA. The second involved xref @type, where we had correctly identified topic, fn, and table, but not li, section, and fig. The third could also affect other formats; when every cell in a table row is vertically straddled, leaving the row empty, the result is invalid. We fixed that by removing the empty row, and resetting the @morerows of the straddling cells to reflect the now-missing row. David Fass was generating OmniHelp, and setting NoRef for some of the heading formats in [HTMLStyles] to suppress the hash part of the contents entry, but that part remained anyway. We had omitted processing of it in OmniHelp, though it was handled correctly in all other outputs; it now works in OmniHelp too. Jack Parkes stopped getting an .hha file produced for his MS HTML Help, and we found that the failure was during the .hhk generation, as a result of a minor inconsistency in two index entries, "a:b" and "a, b" which we should have treated the same way. We do now, and handle any similar cases more gracefully. Anne Smith sent in a test case where there were graphics generation problems. Those turned out to be internal to the FrameMaker graphic export filters, but we noticed that when the graphics were set to run in to their para, a second copy of the graphic was incorrectly shown above the paragraph. That's fixed now. Levi Holmes told us that even if he set [Table]CellAlignAttributes=No, he still got align and valign in DITA entry elements. We had been enabling those based on the table type, without regard for the setting in [Tables]; we've corrected that oversight. Alison White couldn't get [HTMLStyles]DListDD to work to make dd items in a dl list. It turns out the program expected ListDD instead. It now works as documented. James Leedham was surprised to see that the automatic <$prev>/<$next> navigation macros, when at the start of a file, went back to the start of the previous file, even when it had later split parts. He wanted it to go to the last split part instead. We've implemented this quite reasonable request. As a result, the macros now work correctly when StartingSplit is allowed and used; they ignore the empty first file (which is also omitted from any TOC produced). Then we went further, and overhauled the methods used for referencing the previous and next files. We've deprecated the [FileSequence] section, instead using the .lst file we generate from the .book. That eliminates possible transcription errors when using [FileSequence]. We've also deprecated the predefined macro variables $$_firstsfile and $$_prevsfile, since they were only needed for workarounds when using StartingSplit. We added several new sections in the .ref files to contain the info needed to make all this work automatically. We also added another layer of indirection for the macros used at the start and end of the book, by adding two new settings for the titles used in them. At the same time we added macros and titles for Top: [NavigationMacros] ; TopMacro = content to put out for <$_top>, link to top of current file TopMacro= <$$_toptitle> ; StartingPrevFSMacro = <$_prev> to use at start of first file in book StartingPrevFSMacro= <$$_seqstarttitle> ; EndingNextFSMacro = <$_next> to use at end of last file in book EndingNextFSMacro= <$$_seqendtitle> ; ; TopTitle = definition of <$$_toptitle> TopTitle= Top ; StartingPrevFSTitle = definition of <$$_seqstarttitle> StartingPrevFSTitle= At Start ; EndingNextFSTitle = definition of <$$_seqendtitle> EndingNextFSTitle= At End Since some people seem to have a need to use *both* button and link navigation macros in the same file, we made that possible with an added set of macros specifically for the buttons; the normal set applies only to the link form. You can switch between the default link and the button macros by setting UseNavButtons appropriately in a config macro such as <$$[NavigationMacros]UseNavButtons=1> to use the buttons, or alternatively <$$[NavigationMacros]UseNavButtons=0> to use the links, before using the calling macros <$_top>, <$_prev> and <$_next>: [NavigationMacros] ; When UseNavButtons=Yes, these (modifiable) macros are used instead: TopButton= PrevButton = NextButton = PrevFSButton = NextFSButton = StartingPrevFSButton = EndingNextFSButton = Adam Light had some books where tab was used for specific purposes rather than tables, and wanted to be able to replace the tab characters in some formats with code in a macro. We added: [StyleTabReplace] ; doc style = HTML code to use instead of tab sequence, can be macro This can use either a char style or a para style. Nothing is needed in [HTMLStyles] to flag it, just use that section by itself. The macro runs once for each tab sequence, not for each tab, so if the doc has one tab in one para and three in a row in another, to get to the same spot, they will be treated the same way. Any open inline elements like are all closed before the macro runs, and any new tags for the following text are opened after it runs. Adam Light also found that having a null value for a [ParaStyles] format caused a crash. We fixed this bug, and at his suggestion now interpret the null value as equivalent to setting [HTMLStyles]NoPara for the format. For RTF (build r291), Lou Swift found some problems with producing active autonumbers (SEQ fields) in Word output. If there was no prefix text before the first field, the SEQ fields were omitted. When an autonumber format set a level to zero for subsequent autonumbers, that setting was ignored. When the last real anum level had suffix text, and was followed by empty levels, the count of suffix characters was incorrectly deleted after the empty levels. We fixed all of these bugs. Michael Long reported that lines in Word RTF header framess drawn from Reference-page frames were not aligned correctly with the other text in those frames. We've corrected that. We also noticed that for the Word versions that use a default graphic unit of "himetric" instead of "twips", the correctly-computed scaling factor of 176 did not always look right, so we added: [WordOptions] ; PicScale = 176 (default), percentage to expand graphics for Word ; 8/97, 2000, and 2002/XP to compensate for redefined Word default. ; Adjust as needed; Word 2000 seems to do better with 178, for example. PicScale=176 For MIF (build m205), Lou Swift's test case had autonumber formats that used the illegal building block instead of the correct . We were less forgiving of this than Frame, adding the ">" to the suffix text after that level, but we now watch out for that problem too. Stephan Will kindly informed us that when a Frame 8 file referenced a symbol font such as Wingdings 2 at code points in the Unicode C1 Controls range (0x80 through 0x9F), we were not rendering the correct characters in Word RTF output. Upon further study, we found we weren't in HTML output either. Frame 8 evidentally broke back compatibility with Frame 7 in this area, so its Frame 7 MIF output is also (differently) wrong; so is its native HTML output. Its native RTF, however, is correct. We have handled this with changes to drmif, dwrtf, and dwhtm. We note that Firefox 3 declines to apply the Wingdings 2 font to the characters above U+00A0, even though the font has glyphs for them; IE6, however, does render them correctly. This appears to be a Firefox bug. We had noticed that in some cases, when the FileID file was missing, graphics would be produced that lacked FileID prefixes on their names, but the references to them in the HTML files would have the IDs. This was because drmif gave up on IDs when mif2go.ini was missing, but dwhtm created a new mif2go.ini. We've changed that so that drmif also creates a new one if necessary. Robert Lauriston found that UTF-8 characters in variable definitions were not always handled correctly. We fixed that bug. For the plugin (m2rbook build b109 and m2gframe build f005), we added code to support the logging facility. We added log entries to report in detail about any problems encountered during template import and during graphics generation. As a result of James Leedham's enhancement above, we now can remove the empty starting files when [HTMLOptions]StartingSplit=Yes *and* the first head in the file is set for [HTMLStyles]Split. Since they still serve a purpose in the output directory, we remove them from the Wrap directory, when [Automation]WrapAndShip=Yes. =======================================================================