Some past notes regarding two processes this blog will be dealing with:
(grets) oneups, which take xml data, transform it with xslt
into an xsl-fo file, and run it throughapache's fo processor to get a pdf. This is, compared to the next, a significantly less abstracted and dependentcy-laden process.
crex/nrei documentation, which is a whole authoring environment containing chapters and sections and all coming together with a book file through an automated system.
Hyperlinks added after the fact to point to some (hopefully) useful links should others dive into this stuff.
10/30/2006
FOP on Windows via Cygwin using Docbook: 1) Installing docbook packages in Cygwin with the setup installer somehow killed the fop command in an unexplicable fashion: it was complaining about syntax errors in fop.sh on lines that were empty. Solved the problem in an unconventioanal manner: copied over Chris's working Cygwin directory. 2) Fop doesn't recognize cygdrive as a path; must use windows-style directory paths 3) For some reason fop wasn't displaying gifs and kept asking for JIMI (IBM's image rendering engine not included, but possible with fop), even though gif's are supported by fop natively. Solved the problem by copying all the jar files from the Havoc instal (Z) into the L-drive fop install "lib" directory, which was a fresh download/install from Apache They were all there and the same size, so the problem remains a mystery.
11/2/2006Thursday, March 1, 2007
Aggregation of past notes
Appendix for documentation: pdf? eps?
Decided on combining mutiple pdfs at the end. Figure out how to input special utf-8 characters into emacs, specifically for crextm. SOLUTION: with special character entities. Xinclude implementation issues. Got it to work with xmllint xinclude processing first, but utf-8 encoding for crextm is still an issue.
11/13/2006
continue work on grets stylesheet
notes field: issue with footnote table block incorrectly reading its own width. solved by making flow table width match footnote table width.
made prop id and prop transaction id as table header that profilerates to following pages if table breaks.
11/17/2006
completed mod to grets stylesheet
: notes field, font size increase, some keeps, and margin/region-extent tweaks.
xinclude and catalogs make revhistory, version, etc as parameters somewhere somehow
12/6/2006
made progress on dealing with overflow issues on very nested lists in Crex-manual
12/8/2006
nrei version of grets stylesheet
restructuring of stlyesheet includes to be more semantically correct and faciliate scalability
12/18/2006
overflow issue solved: appropriate margin/region after settings; no more than 3 nested lists, and a hard pagebreak processing instruction at "processing" section.
1/12/2007
xinclude work: made simple test files.
1/16/2007
added newline support to grets oneups
1/17/2007
norm walsh's catalog resolver up and running! (in examples replace com with xml to refer appropriately to directory struture).
put it in Tech/share/catalog_resolver1.2/started on rakefile per poignant guides.THE ORGANIZATION OF PROCESSES The elements we work with for this entire xml publishing system, at sufficient abstraction levels, are: * the files themselves, which are valid xmldocuments. * catalog files, which keep track of uri's and rewrite them appropriately * entity file holding all the shared system entities * aggregator files, like book.xml, that don't actually posess any content, but only link to the content * rubyrakefile that builds the stuff. Firstly, there are the content files, which are their own xml documents, and therefore validate properly. They then get referenced by an aggregar file, which references them through an xinclude statement with a href to the entity defining that file. In other words, the aggregator file includes a bunch of system entities in a bunch of xinclude statements. These aggregator files should be able to be nested.**** problem *****
For the content files to be valid xml, they need to have doctypedeclarations. However, the entities point to filenames, so therefore the entire file gets included with the xinclude statement, which means more than one doctype declaration exists per aggregator document. Is this a problem? Probably. A solution must be found.
Possibly use entities for the doctype declaration, so that when it gets processed alone, the entity resolves. When its included, that entity is not in the shared entity file, therefore is never resolved and therefore never exists.Another solution is the processing flag in xmllint that drops duplicate doctype declarations.
****************
Entities file: There's a global entities file, or perhaps several, that govern the actual content. This affords maximum fluidity of content, because none of the aggregator files will need modification if content resources change, only the entities file will. Furthermore, due to the processing system, there will be no excess duplication of data, since these separate entitites wont come together and resolve until an actual document is processed. The file locations of the entity file will be generic, imaginary uris, which will be resolved by the catalog file. That way this entire system can move across operating systems, differently organized file trees, etc.Catalog files:
Catalog files do one thing and one thing only: remap uris. Semantically, there are two different kinds of catalog files: a catalog file(s) that deals with system resources like cygwin directories, docbook stylesheet locations, and the like, and catalog files that deal with remapping the directory structure of the specific document build. The question now becomes how all these things work together, what the dependencies are, etc. Content files need nothing. They are self contained.
Ok, lets try to get it from functional step to functional step. Goal for today: get the xincludes to resolve properly, and get crextm char entity to resolve properly without the use of catalogs
secondary goal: make the thing work with a rakefile. if successful: commit changes!
xincludes: got Crexentities to parse properly. Wasn't working before due to a typo in the filename in book.xml.
Xinlcude won't parse anything not utf-8. Special character encoding are NOT utf-8, which is why entities are neccessary. Went into Tech and Runbook chapters and replaced all CREXwhatever with the CREX™.
glossary wasn't loading bc the xpointer was 'glossary' instead of 'Glossary'. Must have a capitalization convention!!!
fop's encountering an oversize endless loop in "transaction processing". I've pasted from the corrected full CREX-Manual.xml. Don't know what's cousing it yet.
Ok, lets try to get it from functional step to functional step. Goal for today: get the xincludes to resolve properly, and get crextm char entity to resolve properly without the use of catalogs
secondary goal: make the thing work with a rakefile. if successful: commit changes!
xincludes: got Crexentities to parse properly. Wasn't working before due to a typo in the filename in book.xml.
Xinlcude won't parse anything not utf-8. Special character encoding are NOT utf-8, which is why entities are neccessary. Went into Tech and Runbook chapters and replaced all CREXwhatever with the CREX™.
glossary wasn't loading bc the xpointer was 'glossary' instead of 'Glossary'. Must have a capitalization convention!!!
fop's encountering an oversize endless loop in "transaction processing". I've pasted from the corrected full CREX-Manual.xml. Don't know what's cousing it yet.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment