Regarding internal "links" and cross-references within the BCD, MS Word does support hyperlinks (to figures, tables etc.) within a document. My personal preference would be for a pdf document (which again can be produced with hyperlinked internal references).
Andy. Peter Tenenbaum wrote:
Let me clarify:In the original version of the RTML BCD, there were internal links between my sections and between text and figures, etc. For example, I had many links from text to my figure of the RTML footprint, which was part of the document. Those links no longer work -- indeed, the links in the MSWord version all point to some point in the original Wiki-format version! Either we should decide that hyperlinks within the BCD, between different sections etc of the BCD, are good (in which case we should use a format which supports them) or else that they are bad (in which case they should be changed to references in the MSWord version).As far as the formatting is concerned, I absolutely refuse to take the reformatted RTML node and reformat it again to match the specifications below. I put a lot of effort into formatting the original document according to the specifications of the Wiki page. If the GDE has decided to completely scrap that and start over in MS Word, that's fine, but it's unconscionable to convert the document into MS Word and then demand that I go and reformat it -- the format should be set up correctly in the conversion phase.-PT Shekhar Mishra wrote:Hi PT, Please see my comments below.The intent is to make BCD as self contained document as possible. If the tables, figs etc are important part of the information please put them in the MSword. It will make keeping track of changes easier. I have no objection to Hyperlinks but CCB has no control over those Hyperlinked files. If you want to put the Hyperlink as a reference that is ok. We should not put supporting document in the CCB. It can be put in as reference.Our intent is to Main Author of the subsection to look over the document and fix the editing. We should make it as readable and as Change Friendly as possible.Shekhar Peter Tenenbaum wrote:A couple of comments:1. I originally wrote the RTML node directly into the Wiki's format. While conversion to MSWord has simplified change tracking, I find that the links in my original wiki, which have been transplanted to the MSWord format, no longer work right. I guess that there is some confusion -- I thought that the original plan was that the BCD would be an electronic document, taking full advantage of hyperlinks etc, rather than an electronic version of a conventional document. I would recommend that we do one of the following:a. If the intent was to make a hyperlinked electronic document, perhaps we should use MSWord's capability to save in HTML format -- I think that you can have both the change tracking and ease of editing which are featues of Word, plus have hyperlinks which work when the document is viewed in a normal web browser.b. If the intent was, or is, to make a more conventional document, then the hyperlinks should be replaced with more conventional references to Figure X, Section X.Y, etc.2. I can't quite tell, but I do not think that the MSWord version of the RTML node is formatted according to the links below. Was it the intention of the CCB that the Area Systems Leaders would take the reformatted BCD nodes and re-reformat them to follow the rules below? Or is the RTML section correctly formatted and I just don't understand the style guidelines well enough to understand that it's correct?No it is not formatted to the style suggested. CCB wants the Area Systems Leaders to format the document.Major formatting I did is to put everyone in the same font. Got everything in one place etc. It is a lot of work for me to format every section considering there are a lot of section where there are headings but no text (may be not in your section). May be the author planned to put something there but it is not there. One is requested to delete those sub section heading.-PT N.Toge wrote:Dear Colleagues, This is N.Toge of CCB. The Frascati version of BCD has been converted into MSWord format and the files are now available at http://www.linearcollider.org/wiki/doku.php?id=bcd:bcd_home ... as "current official version", and at http://www.linearcollider.org/wiki/doku.php?id=bcd:dec2005version ... as the "Dec. 2005 snapshot".As a first step I am requesting the main authors of each section to lookover the document, and to apply any trivial editorial correctionsas found necessary and send them back to us at ml-ccb@xxxxxxxxxxxx ASAP.For instance, as you see, some of the very long sections had better introduce an internal subsection numbering scheme which is presently lacking. This type of editorial work will be handled as "Class-0" BCchanges (see my another email on the Change Procedure to be sent out shortly).Also I would like to ask the entire GDE and RDR members to start using these Word files as the starting point for the Configuration Controleffective immediately, i.e. colleagues, please, use track change on thesefiles to indicate suggested edits, BC changes, etc. I have asked Shekhar Mishra (CCB/FNAL) to serve as the "style editor" to ensure the style consistency in the forthcoming document change processes. His suggested style instrutions are as follows - a. Edit with track change on. b. Use "Times New Roman" Font 12 for the Text. c. Use Font 24 for Chapter Heading d. Use Font 18 for section Heading e. Use Font 16 for subsection Heading f. Use Font 14 for sub-subsection Heading g. Do left justified bullets. f. Center the table and figure on the page. If possible try to fit the table in one page or make two tables.We would appreciate hearing your inputs and suggestions for implementingthis practice, improving it and make it a success. Sincerely, - Nobu Toge (KEK, Accelerator Lab) email: toge@xxxxxxxxxxxx voice: +81-29-864-5224 fax: +81-29-864-3182 ps. This email is sent to - ml-ccb@xxxxxxxxxxxx, which includes - carlo.pagani@xxxxxxxxxx daniel.schulte@xxxxxxx g.blair@xxxxxxxxxx kiyoshi.kubo@xxxxxx lwfunk@xxxxxxxx masao.kuriki@xxxxxx mishra@xxxxxxxx toge@xxxxxxxxxxxx twmark@xxxxxxxxxxxxxxxxx ml-ext-gde@xxxxxxxxxxxx, which ihncludes - asiri@xxxxxxxx atsushi.enomoto@xxxxxx awolski@xxxxxxx b.foster1@xxxxxxxxxxxxxxxx bans@xxxxxxxxxxx barish@xxxxxxxxxxxxxxxx brachman@xxxxxxxxxxxxxxxxx c.damerell@xxxxxxxx carwar@xxxxxxxxxxx d.angal-kalinin@xxxxxxxx dieter.proch@xxxxxxx elsen@xxxxxxxxxxxx eskim1@xxxxxxxxxxxxx fumihiko.takasaki@xxxxxx gaoj@xxxxxxxxxx garbincius@xxxxxxxx garvey@xxxxxxxxxxxx gfd1@xxxxxxxxxxx guiducci@xxxxxxxxxxx hfcarter@xxxxxxxx hitoshi.hayano@xxxxxx hosoyama@xxxxxxxxxxx hsp3@xxxxxxxxxxx jcs@xxxxxxxxxxxxxxxxx jct@xxxxxxxx jean-luc.baldy@xxxxxxx jean-pierre.delahaye@xxxxxxx jimbrau@xxxxxxxxxxx jmp@xxxxxxxxxxxxxxxxx junji.urakawa@xxxxxx kaoru.yokoya@xxxxxx kenji.saito@xxxxxx kephart@xxxxxxxx kuchler@xxxxxxxx larsen@xxxxxxxxxxxxxxxxx laurent.tavian@xxxxxxx lwfunk@xxxxxxxx mcrec@xxxxxxxxxxxxxxxxx nan@xxxxxxxxxxxxxxxxx nicholas.walker@xxxxxxx nobuhiro.terunuma@xxxxxx noonanjr@xxxxxxxxxxx norihito.ohuchi@xxxxxx olivier.napoly@xxxxxx p.burrows@xxxxxxxxxx paolo.michelato@xxxxxxxxxx peterg@xxxxxxxx quarkpt@xxxxxxxxxxxxxxxxx richard@xxxxxxxxxxxx seryi@xxxxxxxxxxxxxxxxx shigeki.fukuda@xxxxxx shinichiro.michizono@xxxxxx solyak@xxxxxxxx star@xxxxxxxxxxxxxxxxx stefan.simrock@xxxxxxx sugahara@xxxxxxxxxxx tetsuo.shidara@xxxxxx thimel@xxxxxxxxxxxxxxxxx tommy@xxxxxxxx tor@xxxxxxxxxxxxxxxxx toshiyasu.higo@xxxxxx wilhelm.bialowons@xxxxxxx willis@xxxxxxxxxxxxxxxxxx yhitoshi@xxxxxxxxxxxxxxxx yusuke.suetsugu@xxxxxx