[Expo-tech] files to munge whilst converting VCS

Mon Apr 13 15:57:38 BST 2020

A fine amount of work – and yes I see a couple of those were my fault, put in expoweb when I should have put them in expofiles.

re Brendan’s guides PDFs

documents/tunnel-guide.pdf

documents/survex-guide.pdf

Can I suggest putting them in original size in expofiles/documents  rather than re-packing them?

When used, a beginner would want to be able to zoom in to read the tiny text. So this is not the same sort of thing as a generic  illustration in an A4 document.

There may be other things like that, some of the “poster sized” images ? I wouldn’t know so I’m just guessing.

I have (somewhere) Brendan’s original PPT versions of these and it’s “on my list” to re-render these into the handbook as HTML so that they can be updated more easily when the software gets updated, or when our expo-specific workflow changes or gets better. Such as using *REF now or *QM in future.

aha:

expofiles/training-info/ How to use survex for beginners ppt.pptx 

expofiles/training-info/ Idiots guide to accessing expo git.pptx

expofiles/training-info/ Tunnel guide.pptx

I have just put the Tunnel one there just now. I had never got around to doing that after Brendan shared it with me in Feb.

OK, we should store them as .odt or whatever, but breaking the PDFs  open so that we can edit small updates is what we need to be able to do.

Otherwise I strongly agree with Mark. For the sake of a few megabytes we really do not want to be permanently deleting information. The cost of a MB is all in its management not the actual size, and shrinking a large PDF smaller does not affect the management cost.

Philip

PS The whole troggle database is only 10 MB after importing everything. Shouldn’t we be using an in-memory database these days instead of MySQL ? Or is that not an option with django?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wookware.org/pipermail/expo-tech/attachments/20200413/3d338434/attachment.htm>