Ideas, yes, but I'm not a subject matter expert by any means --- still learning my way around this stuff too. :) I'll provide a detailed explanation here so we have this information in the archives to help anybody else. The clue with these failures is always the first message. In this case, "parser error : Entity 'kicon' not defined." The remaining messages are a result of the first message and can be ignored as they are standard output. Take that specific error message literally. That is, the entity is not defined. We have to figure out what "not defined" means. :) That an entity "is not defined" means 1) the entity is not declared anywhere in the entire doctype definition set, 2) an incorrect DocType declaration in the affected docbook file, or 3) something wrong with the DocType definition document (dtd/kdex.dtd) --- which is a long chain of docbook dependencies. All of the reasons mean that an entity is not defined. Fundamentally, kicon does not exist in any of the included entity files, or an entity file containing the definition is not included in the entire chain of docbook dependencies. In this case, the entity &kicon; does not exist in any of the included entity files. Why? In user.entities, I changed that entity name from kicon to ticon. For standard help docbook files, when looking for allegedly undefined entity definitions, there are two primary entity files to search: general.entities and user.entities. In an installed system: $PREFIX/share/apps/ksgmltools2/customization/entities/general.entities $PREFIX/share/apps/ksgmltools2/customization/$LANG/user.entities Where $LANG is the two character abbreviation for the language base. Pay attention to the error message to notice which language is affected. In this case, "en" was specified. In this case searching both general.entities and user.entities does not contain a declaration for kicon. When that happens start looking for obvious renaming, such as ticon. The easiest way is search both files for "icon" and that would lead to finding ticon. Hint: we know these help files compiled and now they don't. That is, the referenced error entity once compiled but now doesn't. Hence, look for renamed entities. The cure in this case is to search and replace the krusdader docbook files and replace "&kicon;" with "&ticon;". Searching and replacing with the ampersand and semi-colon is necessary because there always is a chance the full text could contain a snippet set of characters with the same pattern and we don't want to blindly replace those occurrences. We want only to replace entities. When using sed, be sure to escape the ampersand and semi-colon (use the backslash). I don't remember which of those two characters is problematic with sed. Every time I don't escape one of those two the resulting replacement ends up with "&kicon;&ticon;" or something similar. cd applications/krusdader find . -name *.docbook -exec sed -i 's|\&kicon\;|\&ticon\;|g' {} \; Yes, I need to post the short list of the entity names I changed. :) I'll add that to my to-do list. The list is very short but will help with troubleshooting these messages. Further, I need to create a list of remaining docbook files that will be affected by these few renamed entities. As I have tested thoroughly with all of the main suite modules and a dozen applications, that list of remaining apps should be short. Much like cascading style sheets, docbook doctype definitions use a layering system to contain all the needed information. I hope one day to write a wiki article how the entire Trinity help book system works --- after I actually understand everything. If anybody has any experience with docbook and wants to help me write that wiki article, please be welcomed to help. :) Darrell