Ferdinand von Mueller's correspondence upconversion from MS Word to TEI XML
License: Apache License 2.0
I have created a sample set of files with images.
Can you test the approach before I go through all the letters and extract image files?
The test set has a range of features: embedded small images, drawings on seperate sheets; pure line drawings, and some that have graduated tones, including photographs.
The sample letters, and the images, are in the folder dropbox/Conal working files/copies of M letters with images. There are two folders inside that one: letter copies and images.
The images have been saved with file names of the form yy-mm-dd_image0x.jpg.
The letters have been saved with a file name yy-mm-dd-_status_IMAGETEST.doc.
The point in the transcription where an images appears has a footnote in various forms to suit the situation but including in all cases the name of the relevant image file, for example, 'For sketch, see yy-mm-dd_image01.jpg.'
There is one file with 10 images, hence the form of the file name; although I don't think it necessary to have them all with a leading zero, it is a useful way for me to be able to keep track. If it causes you problems I haven't foreseen, I can change the format by removing the leading zeros where less than 10 image files are associated with a text file.
I hope that this is sufficient to test your processes on a set small enough to be manageable, but large enough to be representative.
I have cleaned all but one problem in the final files.
The remaining one is with the style in the analytics labelled 'footnote reference' and affects 60 files, resulting in a style label Footnote%20text and footnote numbers suppressed in the footnote.
There was what I thought was a lucky a lucky accident that would help me see what was going on, that resulted in an earlier version of a file and its final version both present in the set, and only the final versi0n is affected:
Version with problem:
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1860-9/1862/62-06-06b-final.xml
Version without:
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1860-9/1862/62-06-06b-final.xml
I assumed it would be something to do with the styles present in each file, and although I could find a difference using the Word style listings, this was not a consistent difference between affected files and those not affected.
I tried overwriting the styles in the affected documents with the styles from the template, either one by one or en masse, and have not achieved a solution.
I am not familiar with XML coding, and don't know what to look for in those versions to try to get a handle on the issue.
It seems that it is something that has been happening when Rod was making files final, as there is an extremely low incidence of it in 'not final' files, 8 in 10,392 files compared to 60 in 5181 final files.
I would like both to remedy the problem and ideally to understand how it arises so that we can prevent more accumulating when we start setting more files to final from the week after next when Rod returns form China.
Another one for when yiou get the funds.
Some letters can't be dated more precisely than to the decade.
The problem is having items dated to both the decade and those for which a month can’t be assigned in the 0th year showing up as X0-00-00x
I think that there is a way we can distinguish them, without introducing new codes. If we create a new folder within each relevant decadal group, called something like X0sBroad we could indicate by their position in the filing system the ones that were broadly dated, a distinction which would show up in the citation if we use the system of citation generated by Conal’s XTF.
So, for example, we would have folders patterned like this:
1870-79
70sBroad
1870
1871
1872
&c
Rod was not sure what this would be like in practice. He said
I agree that it's highly desirable that we separate the two kinds of file, but I don't know that what you propose will fit the bill. It will clearly effectively separate things in our working files, but we surely also need the difference to show up when a file is viewed on-line? Or are you saying, in your sentence referring to Conal's XTF, which I don't really understand, that the different character of the two kinds of files will also be evident when viewed on-line?
I replied
My comment about Conals XTF citation depends on how we recomend that citations be made.
At the moment, if I search for 60.00.00a [note . not -] in the XTF files, and then select the citation option from near the top right of the window, I get as the citation "http://vmcp.conaltuohy.com/xtf/view?docId=tei/1860-9/1860/60-00-00a-final.xml”. If we follow my proposal, it would come up as
"http://vmcp.conaltuohy.com/xtf/view?docId=tei/1860-9/60sBroad/60-00-00a-final.xml”, showing that it was not in a specifc year within the 1860-9 group.
For the final version the vmcp.conaltuohy.com would be replaced by the server address holding the letters
If we recommend a different citation, then this may not work.
But the citation would need to be checked for this to show up. However, when we decide on what the end user is going to see, we could ask that a "cite as” statement appears at the top of each letter. If that could be done, then this will solve the problem. Wewould need to ask for something like “Cite as Home et al, Correspondence of Ferdinand von Mueller, …” where the ending is unique to each letter, something like the current "1860-9/60sBroad/60-00-00a-final.xml”
If a user choses the “data” facet, then instead of the current
collapse data
collapse 1860-9
expand 1860 (111)
expand 1861 (113)
expand 1862 (170)
expand 1863 (169)
expand 1864 (169)
expand 1865 (203)
expand 1866 (208)
expand 1867 (152)
expand 1868 (133)
expand 1869 (171)
there would be an extra line above 1860, saying “60sBroad” or whatever we call the folder.
This will need to be kept in mind when the final, user, display is being designed.
We have used underlinings in the transcriptions; but they are not displayed, and as it is an important element. they should be.
For an example see
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1880-9/1886/86-07-02-final.xml
in which
the office held by the claimant and the place of his employment.
was underlined.
To be able to deal with the upright fractions by eliminating them (see #41) we need to be able to find files including them. They were created using "equations" in Word and, like images, are represented by an asterisk in XTF display, see for example footnote 3 in
http://vmcp.conaltuohy.com/xtf/view?docId=tei/Mueller letters/Mentions/Selected Mentions letters/M64-02-22-final.xml
Is it possible to find these and display as a "feature"?
e.g. sanitise the # in tei/inscriptions/TO Mueller/79-00-00Moeller_a#1012.xml
See the table in the footnote in this document:
https://view.officeapps.live.com/op/view.aspx?src=http%3A%2F%2Fvmcp.conaltuohy.com%2Fdoc%2FMentions%2F1890-9%2F97-02-19Rogers-Poole.doc
Compare with the OpenDocument version:
http://vmcp.conaltuohy.com/odt/Mentions/1890-9/97-02-19Rogers-Poole.odt
Arthur says:
... 92-10-15, has a large } spanning three lines in an existing table, which is more or less OK in XTF, but the table had only one row. To control the problem with the tab spacing, I have had to create a table with three rows in the first and second columns, but with only one row in the other two columns. I do not expect this to present well in XTF, but it is a good example to try.
In your e-mail 13 Dec 14.27 you wrote
Having excluded the empty paragraphs from the count, I've reduced the number of documents with "standard"/"normal" paragraphs by 50%, which, although a definite improvement, is still (I would think) too large a number to be manually corrected. However, I think some kind of correction will be needed, since a quick random survey of the "standard" texts shows almost all of them have paragraphs which are clearly intended to have some special significance but are still styled "standard". So I am tending towards the idea that it will indeed be necessary to automatically replace the "standard" style of those paragraphs, based on their direct formatting and content.
It does look like it will be necessary.
If that fails can you further segment by selecting the XML files with -final as the suffix of the file name?
If there is a smallish number of those, then we can tackle those manually and keep a good watch on the others as we set them at final. There are at least 26 of them at Final, as we have done all up to 1859; Mentions is a mess as yet, with mostly first drafts, so tI suspect that most of the 118 that include standard style will need working in in any case.
The same files I checked last night are stll showing the problems after the midnight update.
The problem file you identified with the very strange table structure has been restructured, but effects are not apparent:
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1860-9/1862/62-07-04-final.xml
A file that had a very odd appearance in XTF--a section was coloured as if it was a footnote-- turned out to have a very odd Word styles structure: that part of the file was reported as having no style! This was redone so that the style structure was correct:
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1890-6/1891/91-06-29-final.xml
Two files that showed up a very strange set of symbols in a footnote were redone, by deleting and renetering the footnotes concerned:
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1880-9/1887/87-06-16-final.xml
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1880-9/1887/87-06-18-final.xml
There has also been, I think, another change of behaviour, but as I did not keep an exact record I can't be 100% sure, but my memory of the previous behaviour is I think pretty good because I used the characteristic now lost. Now when I enter a search term such as 87.10.26 only the file with that exact name is returned. Previously the list of selected files would also have included 87.10.26a, 87.10.26b and 87.10.26c. At present I can only get those with suffixes if I ask specifically for them, which presupposes I know they exist.
I suspect from this search case that the change is a result if the tweak to handle deleted files, and the timing suggests that the failure to load the changes is also probably something to do with that. This is of course just an hypothesis about what is happening inside what is to me a black box (I have no desire to learn how to make that box transparent to me!). I hesitated before suggesting it, just in case I started a red-herring chase, but in the end I thought it worth suggesting.
For when you get funds:
Some letters do not have a specific addressee. For example
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1860-9/1865/65-10-00-final.xml
This is a effectively a circular press release sent by Mueller to a number of newspapers.
At present the author facet shows "Ferdinand von Mueller?" and the Addressee is blank.
Another similar file
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1860-9/1865/65-06-00-final.xml
also gives the Author as "Ferdinand von Mueller", but the Addressee as "Press Relese".
Other instances of such correspondent lines are Advertisement, Notice, Examination paper and so on.
We have been using the diagnostics in the Facets to ensure that all files that have a defined addressee start with either From, in which case the Addressee is Mueller (except in the cases discussed in issue #42) or To, in which case the Author is Mueller, and the Addressee the text after To. Assuming we have been exhaustive in our corrections, then files set at final that start with neither From or To, will be of this sort, authored by Mueller. Files not yet final will be corrected as we come to them.
Can you adjust the faceting algorithm?
If you would find it easier for development and testing, I can add a folder containing example files for this issues and #42 to the existing drop box folder labelled Conal working files.
@LucasHorseshoeBend commented:
At what stage will we develop a display version? It will need to be before we get the whole 15K files to final? We want to put up a significant chuck, i.e., the files at final, as soon as we can.
There are alternatives to XTF that might be worth considering. Gavan and I agreed on using XTF for the proofing phase mainly because it was "to hand" (I was working with it for another client at the time), and because it was known to have quite good faceted browsing features (which I think have proven to be useful for "slicing and dicing" the corpus), but I think its user interface is less than ideal. These may not matter so much for "internal" use by a small group of editors, but for a publication platform they are more significant. We can certainly set up a public version alongside the proofing version (perhaps including just the "final" texts); there's no need to wait until the entire corpus is done I think.
Currently an empty paragraph will be converted to <lb/> but this should be <space dim="vertical" unit="lines" quantity="1"/>
See http://vmcp.conaltuohy.com/xtf/view?docId=tei/1880-9/1882/82-09-04a-final.xml
It shows up with ... as title.
I opened it, but could not see what might be causing this. It was resaved, so if the effect disappears, well and good, and sorry fro a red herring!
The line "Dated this 26th day of Septr 1872" should be formatted in a couple of different typefaces.
It has just struck me that we might have a potential problem working as we are, but I also hope/think that it will not turn out to be a problem.
When, as you have been doing, you fix the problem cases on files we have not yet finished working on, we will lose the facility of identifying those with problems and might miss them as we finalize them.
For example, http://vmcp.conaltuohy.com/xtf/view?docId=tei/1880-9/1887/87-08-17b.xml as it is in your files at the moment has had a table introduced by your processing that was not there in the original source file. So it will not appear as a problem case anymore with even tabulation. This file has other problems, standard style instead of letter style in part of the text, and uneven tabs but I will not change it at this stage until you look at it and compare with the source file to see what I mean.
Perhaps this will not be a problem, as even if we missed fixing it, it would be fixed again as it is reloaded?? Am I right?
If I am not right, the solution would be to work on just those files that have the suffix -final.xml. I hope I am right, because we should then be in a position to catch every problem when it is loaded as final, even if we as editors miss correcting it.
We have as of today 5302 files set at final
They all should have something styled as number, but the analysis shows only 5298 with that style.
I can't immediately see a way of finding those files; do you know of a method?
capturing the date last changed (and whatever other metadata can be extracted) from the Word metadata, and using that to create a facet
For when you get funds:
Example file:
http://vmcp.conaltuohy.com/xtf/view?docId=tei/Mentions/Selected Mentions letters/M52-10-08-final.xml
I noticed a problem with mentions letters coming up with Mueller as the author; we fixed it by starting the correspondent line with From. The Author facet now helpfully shows up as, for example, "Charles La Trobe to Ronald Gunn". But the Addressee facet for these files shows "Ferdinand von Mueller".
I suspect that the algorithm needs to be tweaked to check for to in the text of the correspondent style, so that the part of it after to is identified as the Addressee. It would be a pity to lose the current identification of correspondent for these files which shows up everything after From, but if we have to, then it's a price I think worth paying to prevent Mueller being the default Addressee.
As of today there are 304 invalid documents (up from 4!)
An automated process to generate and save a detailed report when validation fails would be very handy since the XProc schema validation steps only report that the schema failed and don't say specifically what was wrong with a document.
I see that you have been looking at font sizes, typefaces and the like. As you will have deduced some of the very infrequent ones are probably editorial errors, for exampe the
• font-style: italic; background-color: #ffff00; (1)
in
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1880-9/1886/86-12-13-final.xml
is certainly an error
This is useful to know for debugging. I will work on the infrequent or odd looking ones in the group shown as final in the status heading. and keep the list along side me as I work on others that are being set at final. So when you reload another edition, a lot of those should have been removed in the final set. See new issue on editions
As far as I know the only font families that should be present are Geneva and Times.
I infer this is an attempt to determine what styles should be attached to the files showing up as standard in the styles facet. Would it help if I sent the specifications for each style in the template we are using?
I have been looking at "final" files selecting by "German".
I then chose "1858" in data, and found 10 files (as of today, this might in principle change); scanning down the set of files that show up in the right hand pane shows some with no title, other than the standard suffix " ... [tei symbol]". None of these, for example http://vmcp.conaltuohy.com/xtf/view?docId=tei/1850-9/1858/58-10-07a-final.xml
contains any non-English text.
Any idea what is causing this false positive for German?
Why no name?
Are the two issues related?
Unless this is simple, leave it until pressing display problems, like underlines and alternate font indicating printed, rather than manuscript, components of a text are solved.
Display TEI keywords as facets
e.g. the table in 44-08-04 should look like
Tables that are defined using tabs ("tabular sections") should be converted into TEI tables.
Need to clearly distinguish tabular sections from other uses of tabs, such as to indent paragraphs.
Some tabular sections will be unevenly tabulated, because a variable number of tabs will be used to achieve the same alignment on different paragraphs, depending on the width of the text in those paragraphs. These tabular sections should be excluded from automatic conversion to tables, and left as a residual to be manually edited.
Works well. Found no bugs.
Daily updates will be fine at the moment
Display class names (styles)
Render TEI space element
1870-9/1872/72-09-26-final.xml is invalid, with a couple of empty <row/> elements. Why?
The plant names could be validated using the Catalogue of Life or similar.
This would facilitate QA by picking up typos and other problematic names, which could then be edited.
For later publishing, it would facilitate linking from Mueller's citations to relevant online resources.
As a simple example see
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1870-9/1872/72-09-26-final.xml
[I can't see why this file is returned as the only invalid file now in the set of files: can you?]
In the second tabular block Ern Ommanney should be aligned with F.R.G.S. I think the misalignment is caused by the footnote.
I could ensure alignment by having a three-row table, but we tried to improve appearance by minimising horitontal row margins.
Alignment is absolutely critical to meaning in many files. The best example of problems is
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1840-9/1840-4/44-00-00-final.xml
The first table, below "Ostern 1847" shows the issue is not due solely to the insertion of footnotes under the paragraph containing the footnote reference number. Parmelia in column 1 should be aligned with Carex in colum 2. In this case I think I understand what caused the problem: when I was cleaning up the original---your extremeely useful diagnostics showed it was a complete mish-mash of styles and it turns out that there was a lot of manual adjustment to make it "look right"---I did not match the empty paragraphs in column 2 to the apropriate style in the first column. However, in the next table, either the footnotes or the differences in the width of the columns relative to the text in the source document and the XTF (or both) have caused the misalignments. Once again, having seen this display, I think I could fix at least part of the issue by forcing paragraps at line breaks, but that would not remedy the footnote problem, shown most clearly in the table under " d. 11. Oct. 1845. ", where the original had an entry in each column in each row, so that "Zostera minor" was in the same row as |26 | Ex | in | 8 | [...]
I know we are working in edit view, but it woulp help if I were able to get a good idea of what an end-user view would be. At the moment I do not have a feel for the final effect of our efforts to control displays, avoiding inserting lots of tabular rows which do not "feel right". But it looks as if to control alignment we may need to do this, or a differnt way of displaying footnotes be devised.
There are other alignment problems in
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1840-9/1840-4/44-00-00-final.xml, which I will need to try ot work out how to control, becasue tables are not an easy solution: see the list starting "Callitriche autumnalis. L." where the species names are aligned to the right of the relevant genus, controlled in the file by empty spaces, but which would not easily be replaced by tabs for the reasons you have pointed out before. Compare the source file with the XTF for the 9 species listed below "Potamogeton lucens. L." I need to think more about this.
Daily updates are very useful: as yesterday I corrected the tabular layout in a number of files, and I can now get timely feedback so I can see the effects and check my understanding of the effect of the transformations in the pipeline. Thanks!
What time are the updates set to commence?
If it is easy, but not if you have to spend a lot of time on it, can you set a facet that would allow as to select items by their archival location?
This would facilitate checking what files located where still need to be proof-read.
Thinking ahead a little bit.
The apparatus files contain items that will need different treatment.
Initially I want to work on the two bibliographies, that containing Mueller's publications, and the editors citations. I will work first on the Mbibliography.
My understanding of the teleconfernece session Rod and I had with Gavan is that to make it possible, or at least to facilitate, linking of the citation to Mueller's publications we need essentially a discrete item for each publication, which I assume to mean a database with each publication listed as a discrete record.
We could do a cheap and nasty database by treating the Mbibliograpy as a tab delimited file and importing into a data base, as I have verified by importing a sample, saved as .txt, into Filemaker pro. That gives just two fields, the reference number and publication details. However, since I need to do a great deal of cleaning of that file, I think we can do much better, by inserting tabs in the right place to produce a tab-delimited file with the following fields:
reference number [I would add a B in front of this so that it matches exactly what is in the footnotes, and presumably would make your linking algorithm simpler]
Author [Which will be Mueller or Mueller and another--in the current file no author is given unless joint, and these are coded as yy14.xx I could omit Mueller and the second field would then become additional author, but it is easy enough to insert Mueller as the author by using an all-change command so that each record is a compete bibliographic record. I assume that the original publication upon which we built omitted Mueller as "obvious" and /or to save space in a printed version]
title
publication details [these currently omit year of publication because that is included in the code: to complete a bibliographic record in a standard form the year would need to be inserted, but I think manually, so I will rely on tye code to give the year]
notes
Before I start on this seriously, is there anything else of which I should be aware?
Another issue for when you are funded again for vmcp work.
I have been using the addressee facet to help clean up errors in the correspondent field.
When I facet by "addressee" within "final" it returns some addressees as "the", (today, 172 files).
But when I click on the "the" facet link, it puts all of the final files (today 6151) in the selected set.
This must be an algorithm problem.
There are cases which would show up that way. An example file that will be reported in this way is
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1860-9/1867/67-02-00d-final.xml
The fact that it is reported in this faceted set is not the issue: we could attend to it and others like it if we could easily find them.
Another oddity is that when I click on the addressee reported as "[?]", which suggests that there is one such item, the set conains 18 items, the correct one
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1890-6/1894/94-07-00g-final.xml
and 17 which are reported as "[...]", such as
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1860-9/1865/65-09-00a-final.xml
whereas there are only 3 that are reported as "[...]", including
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1860-9/1865/65-09-00a-final.xml
All this suggests that there is more than one condition where the faceting algorithm is behaving oddly. These facets are extremely helpful in cleaning the files, but I need to have confidence in them.
I suggest that we do not load another edition from the dropbox into the pipeline until the new year. We will have a number of isues clarified/corrected in the final set by then, and there will likely be a bit of a slow down if Rod takes time off in January. I probably won't let up as the weather is more conducive to desk work than even garden work!
If you are planning to have a break, the best time to reload would be when you get back to this project.
@LucasHorseshoeBend via email:
What I was trying to prevent was the display shown in the second and third columns of the top table
http://vmcp.conaltuohy.com/xtf/view?docId=tei/Uneven tabs file sample— edited/63-05-16-final TABLE EDIT.xmlWhat appears is
1
bis
10
u.
35rather than
1 bis 10 u. 35
Here is a case where the display can really inhibit or facilitate getting the meaning of the text.
See as an example footnote 2 in
http://vmcp.conaltuohy.com/xtf/view?docId=tei/Mentions/1860-9/M64-02-22-draft.xml
What is displayed at the end of the line should be in the form of a fraction, 51 over 9187.
There are other examples. In this case and some others it could probably be writen as "51/9187", but that is less representative of the document.
In
http://vmcp.conaltuohy.com/xtf/view?docId=tei/Mueller%20letters/1860-9/1864/64-02-00a-final.xml
we have used an equation format to display a T with a bar over it as a fraction, which is a case where the form "/T" does not represent the chemical sybolism at all. This same line should have the first numeral 3 as a superscript and the second as a subscript.
Any ideas?
Failed trying to find in XTF a letter M68.01.02 that was known to be in the folder: I got a report "Sorry, no results..." When trying to open the folder itself by navigating to data/Mueller letters/Mentions/1860-9 I got the message
net.sf.saxon.trans.DynamicError: Error at character 68 in regular expression "^data::Mueller letters::Mentio...": invalid range (start > end)
Six of the eight files beginning M68 in that folder were found searching for M68.* Thus it is not general, and I was able to expand to the facet data/Mueller letters/Mentions/1860-9 where I could see all but M68.01.02 and M68.06.21
e.g.
<p rend="letter"
style="font-family: Geneva; font-size: 12pt; "
xml:lang="de">
<seg style="">Datvm Kiliae Holsatorum A. D. </seg>xii.
<seg style=""> m. </seg>Maji<seg style=""> a. MDCCCXL</seg>VI<seg style="">.</seg>
</p>from tei/1840-9/1845-9/46-05-12-final.xml
The tabular layout is apparently discarded by the OpenOffice converter when converting the Word document to OpenDocument format.
Reported by @LucasHorseshoeBend
This is not one for which I can think of a suitable work around, but if it's not possible to preserve these layouts in notes, then I will have to explore other ways of doing it.
e.g. in /tei/1840-9/1840-4/44-00-00-final.xml:
<term>Batrachospermum moniliforme</term>
<term> viride</term>See http://vmcp.conaltuohy.com/xtf/view?docId=tei/1890-6/1893/93-02-08-proofed.xml
To preserve the logical of the groupings made in the source text it is neccessary to use tables in the note. These do not display at all.
There have been other instances where tables were originally used in fns, purely for display purposes, but I was able to reformat them adequateley. That option is not open in this case.
I had a look at a sample of the letters in the set created by final status and hypertext style. I was expecting 24 hits, and there were 25.
However, this is a coincidence: ones I expected were like
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1890-6/1893/93-05-27a-final.xml
Ones that I wasn't expecting included accidental links left in when editing include
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1850-9/1857/57-03-05-final.xml see fn 3
If you are able to distinguish between cases where the text contains http:// &c and those that don't it would facilitate clean-up. While the links like the second example are not a fatal problem, they might create an expectation in the reader than will not be met.
If this is difficult, then their are few enough to work on manually.
There also seemed to have been some false positives:
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1850-9/1850/50-02-18-final.xml
See http://vmcp.conaltuohy.com/xtf/view?docId=tei/1890-6/1891/91-07-02a-final.xml
In the display, the paragraph beginning "I find, that I erred..." is displayed oddly, without a style label. The analysis you have set up shows no unusual styles, and the Word verison has the same style for that paragraph as the others in the letter, all of which display correctly.
I do not know how widespread this issue is, as I ony noticed it when I opend the file for other reasons.
e.g. the table at the bottom of this letter:
http://vmcp.conaltuohy.com/xtf/view?docId=tei/1880-9/1881/81-01-20.xml;chunk.id=main;toc.depth=1;toc.id=;brand=default
The "apparatus" files can be quite long.
The Editors citations is 2.3MB (occupying 87 A4 pages)
Mueller's publications, 1.8 MB, 136 pages, but with some shortish, introductory, distinct components. There is a bookmarked pdf version in the dropbox: VMCP/Apparatus files/Mueller's publications/M Pubs 3 ed to 21 Feb 2021-draft.pdf that shows the structure. This is a file likely to be browsed as well as searched.
Honours, awards and memberships, 118KB , is almost certainly to be mainly browsed, as there are things there that no-one is likely to search for unless they are very knowledgeable. The relevant pdf is bookmarked at two levels, country & city within country.
Complete files are easier for us to maintain, so I would prefer not to have to split the files, as I have done as an example in the case of the interim biographical register, where there are 19 segments.
I have not tried using bookmarks in Word, but should I try to create a test file to
a) see that I can master it and
b) to see how it behaves in the pipeline?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.