gifs make compilation go wrong

[i-tietz]

A few of our images cause errors on compiling ... I get the message right before compilation should be finished, means, everything's fine for about half an hour (compilation time increased heavily, but that's another post). The messaege tells me, that there is sth wrong with the HTML Help Compiler. I try to save the Flare log and Flare wouldn't let me. Luckily I was able to copy it to an .txt file.
I cannot open the created .chm file either ...
A few of those images that are causing problems are part of the stylesheet (shortcut links and list-style-image), but not all of them. And some of those being part of the style sheet are ok ... I haven't got a clue.

And this is the relevant message text from the very end of the report:

Code: Select all

HHC3004: Warning: willkommen_lernprogramm.gif : The HTML tag "ø;" is not a valid HTML tag (it does not begin with an alphanumeric character).
images\willkommen_lernprogramm.gif
HHC3004: Warning: willkommen_handbuch.gif : The HTML tag "H,…8BjÉ<吹‚az0T¯Ö,v«íˆç-jýšÏ贝Pˆ‡Êò­X æéö..." is not a valid HTML tag (it does not begin with an alphanumeric character).
images\willkommen_handbuch.gif
images\willkommen_neue_funktionen.gif
images\willkommen_module.gif
HHC3002: Warning: MadCapBodyEnd.js : The HTML tag "gDocumentOnclickFuncs" is missing a closing angle bracket.
SkinSupport\MadCapBodyEnd.js
SkinSupport\MadCap.css
HHC3002: Warning: MadCapUtilities.js : The HTML tag "root" is missing a closing angle bracket.
SkinSupport\MadCapUtilities.js
SkinSupport\MadCapEffects.js
SkinSupport\MadCapEffectsMenu.js
HHC3002: Warning: MadCapGlossary.js : The HTML tag "anchors" is missing a closing angle bracket.
SkinSupport\MadCapGlossary.js
HHC3002: Warning: abrufhistorie.gif : The HTML tag "L" is missing a closing angle bracket.
images\abrufhistorie.gif
images\abruf_kopierend.gif
images\abruf_verarbeitend.gif
images\ab_baumansicht_ausschnitt_datenauswahl.gif
HHC3004: Warning: ab_baum_auswahl_haken_draussen.gif : The HTML tag "È°¡Ã‡+f8Åž	ˆ“H1—̇oþd¤xäÆIè@ZP)‚eÆåürI,	Í..." is not a valid HTML tag (it does not begin with an alphanumeric character).
images\ab_baum_auswahl_haken_draussen.gif
images\ab_dokuverknuepf.gif
images\ab_dokuverknuepf_weg.gif
HHC3004: Warning: ab_fehler.gif : The HTML tag "ñ„hDAb‚R"]°ˆ¸a€$ÜX##Cˆ.^:8@ `Í…jÌ Ày‚	..." is not a valid HTML tag (it does not begin with an alphanumeric character).
images\ab_fehler.gif
images\ab_info.gif
HHC3004: Warning: ab_lupe.gif : The HTML tag "̸&„ǐ#K@¹²åË•;" is not a valid HTML tag (it does not begin with an alphanumeric character).
images\ab_lupe.gif
HHC3004: Warning: ab_menue.gif : The HTML tag "ƪ١,sk!!C÷ÁŒmJ#Ú§*÷6ÀQZ<Ébà éÉò/iéë"#ñGIT‚±•..." is not a valid HTML tag (it does not begin with an alphanumeric character).
HHC3004: Warning: ab_menue.gif : The HTML tag "Ðz`ø+•‡¡·,Ä2µMwPÒ5xjö@Àe†Ovþ8.«"x?‡—^Û..." is not a valid HTML tag (it does not begin with an alphanumeric character).
images\ab_menue.gif
images\ab_ordner.gif
HHC3004: Warning: ab_pfeil_links.gif : The HTML tag "’3]ì—ë»P¬ó;=‚ÑhC¹–´&¨å§@i*§•u[Ö8ì#¯fN2½ŠÞð..." is not a valid HTML tag (
Generated ../../AB-Target/AB.chm
Saving result set...
Output generated in 30 minute(s) and 2 second(s).
Done

Has anybody got a similar problem or is it just me? Means: is it Flare 4 or my PC?
I don't dare to tell my colleagues to install Flare 4, too and try it ... just in case ...

[RamonS]

Wow, interesting characters. Here are a few things that I'd check:
- do the affected image file names include 'special' characters (Umlaute)?
- take a copy of the V3 version of the project (I hope you made a backup) and try to open it again with Flare V4 as a new project, then compile
If none of that works, attach the style sheet to a post here. My guess is that since Flare 4 renamed / added some styles something might have gone awry during that process.

[i-tietz]

Wow, interesting characters. Here are a few things that I'd check:
- do the affected image file names include 'special' characters (Umlaute)?

no.

- take a copy of the V3 version of the project (I hope you made a backup) and try to open it again with Flare V4 as a new project, then compile
If none of that works, attach the style sheet to a post here. My guess is that since Flare 4 renamed / added some styles something might have gone awry during that process.

I'll try that tomorrow ...

And that was a good guess - have a look a new fault:

tables_with_classes_in_flare_4.gif

Those topics have tables that have classes (not table styles, but classes in the main stylesheet).
Result: The Body that includes those tables is treated like a div ...

And it's not the Help Compiler, because I colleague has installed Flare 4 aleready and has the same faults ...
I asked the other colleagues to stick to Flare 3.1 until that is fixed.

p.s.: overflow: auto is being ignored throughout the whole help file - not only in those with tables ...

[RamonS]

Just make sure you report it here as a bug: https://www.madcapsoftware.com/bugs/submit.aspx
....unless you get in touch with Support directly about this. I guess "yelling" at them once is good enough.

[LTinker68]

p.s.: overflow: auto is being ignored throughout the whole help file - not only in those with tables ...

It could be that the overflow property was introduced after the HTML Help framework was last updated. The HTML Help compiler/viewer just doesn't know what to do with it.

[RamonS]

But since the CHM Viewer is based on IE one would assume that it can do whatever IE can do or not do.

[KevinDAmery]

But since the CHM Viewer is based on IE one would assume that it can do whatever IE can do or not do.

Maybe. AFAIK the HTML Help viewer uses code from IE 4 or something along those lines - I don't think it updates to newer IE versions (could be wrong tho' )

[RamonS]

That I don't know either...one more reason not to use proprietary, unmaintained formats.

[i-tietz]

That I don't know either...one more reason not to use proprietary, unmaintained formats.

It's not proprietary, but standard. It worked for years already and this is what the best German website for web technology says:

overflow_settings.gif

This is the help I generated a few weeks ago: No scrollbar - as intended.

overflow_auto_is_working.gif

The problem with Flare 4 is: if the body tag has an overflow it's like it's depicted in my first post. To get the wanted result with Flare 4, I have to transfer the overflow into the html tag. Why that change? No idea.

[RamonS]

That I don't know either...one more reason not to use proprietary, unmaintained formats.

It's not proprietary, but standard.

CHM is a proprietary help format from Microsoft that didn't see any upgrades or maintenance for a decade. It is only a de facto standard (I don't think it is an ISO standard) for the sole reason that Microsoft didn't create any new help formats for the low lives like us to use. They did make a new one, but don't allow anyone to use it.

[i-tietz]

Looks as if you don't like MS.
But that's not the problem - the same MS product was able to interpret the overflow setting last week and isn't able to do it now ...
As you say MS didn't change anything - so it must have been MadCap ...
q.e.d.

[RamonS]

But since it is a closed-source, proprietary format neither you nor anyone else can react to the changes. The problem is that apparently nothing can be changed that doesn't work with a product that is collecting dust for ten years.
I also just compiled a help project to CHM (usually do WebHelp) and it comes out fine with overflow set to auto. Maybe it is something else that goofs things up? I recommend getting in touch with support and have them take a look at it.

[i-tietz]

The problem is that apparently nothing can be changed that doesn't work with a product that is collecting dust for ten years.

Great! If that only had been the case ... but sth DID change ... and it wasn't MS triggering the change ...

[i-tietz]

Update:
- I deinstalled all MadCap applications
- opened the registry and deleted each folder called MadCap Software
- rebooted
- installed Flare 3.1
- installed Flare 4
- deleted the local project
- imported a new version from Source Control (VSS) into the same folder as before
- compiled without errors.

A global tidying up was necessary ... If you get the same/a similar bug: Something to look forward to.