a backup or an export or a migration

.gitignore

+output/
+node_modules/
+content/images/illus-julie-17-18
+content/images/shows
+*.css.map
+
+
+##################
+# Python ignores #
+##################
+
+
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+.hypothesis/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# pyenv
+.python-version
+
+# celery beat schedule file
+celerybeat-schedule
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.venv
+env/
+venv/
+ENV/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+
+
+################
+# Node ignores #
+################
+
+# Logs
+logs
+*.log
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+
+# Runtime data
+pids
+*.pid
+*.seed
+*.pid.lock
+
+# Directory for instrumented libs generated by jscoverage/JSCover
+lib-cov
+
+# Coverage directory used by tools like istanbul
+coverage
+
+# nyc test coverage
+.nyc_output
+
+# Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files)
+.grunt
+
+# Bower dependency directory (https://bower.io/)
+bower_components
+
+# node-waf configuration
+.lock-wscript
+
+# Compiled binary addons (http://nodejs.org/api/addons.html)
+build/Release
+
+# Dependency directories
+node_modules/
+jspm_packages/
+
+# Typescript v1 declaration files
+typings/
+
+# Optional npm cache directory
+.npm
+
+# Optional eslint cache
+.eslintcache
+
+# Optional REPL history
+.node_repl_history
+
+# Output of 'npm pack'
+*.tgz
+
+# Yarn Integrity file
+.yarn-integrity
+
+# dotenv environment variables file
+.env
+

Makefile

+PY?=python3
+PELICAN?=pelican
+PELICANOPTS=
+
+BASEDIR=$(CURDIR)
+INPUTDIR=$(BASEDIR)/content
+OUTPUTDIR=$(BASEDIR)/output
+CONFFILE=$(BASEDIR)/pelicanconf.py
+PUBLISHCONF=$(BASEDIR)/publishconf.py
+
+FTP_HOST=localhost
+FTP_USER=anonymous
+FTP_TARGET_DIR=/
+
+SSH_HOST=localhost
+SSH_PORT=22
+SSH_USER=osp
+SSH_TARGET_DIR=/var/www
+
+S3_BUCKET=my_s3_bucket
+
+CLOUDFILES_USERNAME=my_rackspace_username
+CLOUDFILES_API_KEY=my_rackspace_api_key
+CLOUDFILES_CONTAINER=my_cloudfiles_container
+
+DROPBOX_DIR=~/Dropbox/Public/
+
+GITHUB_PAGES_BRANCH=gh-pages
+
+DEBUG ?= 0
+ifeq ($(DEBUG), 1)
+	PELICANOPTS += -D
+endif
+
+RELATIVE ?= 0
+ifeq ($(RELATIVE), 1)
+	PELICANOPTS += --relative-urls
+endif
+
+help:
+	@echo 'Makefile for a pelican Web site                                           '
+	@echo '                                                                          '
+	@echo 'Usage:                                                                    '
+	@echo '   make html                           (re)generate the web site          '
+	@echo '   make clean                          remove the generated files         '
+	@echo '   make regenerate                     regenerate files upon modification '
+	@echo '   make publish                        generate using production settings '
+	@echo '   make serve [PORT=8000]              serve site at http://localhost:8000'
+	@echo '   make serve-global [SERVER=0.0.0.0]  serve (as root) to $(SERVER):80    '
+	@echo '   make devserver [PORT=8000]          start/restart develop_server.sh    '
+	@echo '   make stopserver                     stop local server                  '
+	@echo '   make ssh_upload                     upload the web site via SSH        '
+	@echo '   make rsync_upload                   upload the web site via rsync+ssh  '
+	@echo '   make dropbox_upload                 upload the web site via Dropbox    '
+	@echo '   make ftp_upload                     upload the web site via FTP        '
+	@echo '   make s3_upload                      upload the web site via S3         '
+	@echo '   make cf_upload                      upload the web site via Cloud Files'
+	@echo '   make github                         upload the web site via gh-pages   '
+	@echo '                                                                          '
+	@echo 'Set the DEBUG variable to 1 to enable debugging, e.g. make DEBUG=1 html   '
+	@echo 'Set the RELATIVE variable to 1 to enable relative urls                    '
+	@echo '                                                                          '
+
+html:
+	$(PELICAN) $(INPUTDIR) -o $(OUTPUTDIR) -s $(CONFFILE) $(PELICANOPTS)
+
+clean:
+	[ ! -d $(OUTPUTDIR) ] || rm -rf $(OUTPUTDIR)
+
+regenerate:
+	$(PELICAN) -r $(INPUTDIR) -o $(OUTPUTDIR) -s $(CONFFILE) $(PELICANOPTS)
+
+serve:
+ifdef PORT
+	cd $(OUTPUTDIR) && $(PY) -m pelican.server $(PORT)
+else
+	cd $(OUTPUTDIR) && $(PY) -m pelican.server
+endif
+
+serve-global:
+ifdef SERVER
+	cd $(OUTPUTDIR) && $(PY) -m pelican.server 80 $(SERVER)
+else
+	cd $(OUTPUTDIR) && $(PY) -m pelican.server 80 0.0.0.0
+endif
+
+
+devserver:
+ifdef PORT
+	$(BASEDIR)/develop_server.sh restart $(PORT)
+else
+	$(BASEDIR)/develop_server.sh restart
+endif
+
+stopserver:
+	$(BASEDIR)/develop_server.sh stop
+	@echo 'Stopped Pelican and SimpleHTTPServer processes running in background.'
+
+publish:
+	$(PELICAN) $(INPUTDIR) -o $(OUTPUTDIR) -s $(PUBLISHCONF) $(PELICANOPTS)
+
+ssh_upload: publish
+	scp -P $(SSH_PORT) -r $(OUTPUTDIR)/* $(SSH_USER)@$(SSH_HOST):$(SSH_TARGET_DIR)
+
+rsync_upload: publish
+	rsync -e "ssh -p $(SSH_PORT)" -P -rvzc --delete $(OUTPUTDIR)/ $(SSH_USER)@$(SSH_HOST):$(SSH_TARGET_DIR) --cvs-exclude
+
+dropbox_upload: publish
+	cp -r $(OUTPUTDIR)/* $(DROPBOX_DIR)
+
+ftp_upload: publish
+	lftp ftp://$(FTP_USER)@$(FTP_HOST) -e "mirror -R $(OUTPUTDIR) $(FTP_TARGET_DIR) ; quit"
+
+s3_upload: publish
+	s3cmd sync $(OUTPUTDIR)/ s3://$(S3_BUCKET) --acl-public --delete-removed --guess-mime-type --no-mime-magic --no-preserve
+
+cf_upload: publish
+	cd $(OUTPUTDIR) && swift -v -A https://auth.api.rackspacecloud.com/v1.0 -U $(CLOUDFILES_USERNAME) -K $(CLOUDFILES_API_KEY) upload -c $(CLOUDFILES_CONTAINER) .
+
+github: publish
+	ghp-import -m "Generate Pelican site" -b $(GITHUB_PAGES_BRANCH) $(OUTPUTDIR)
+	git push origin $(GITHUB_PAGES_BRANCH)
+
+.PHONY: html help clean regenerate serve serve-global devserver stopserver publish ssh_upload rsync_upload dropbox_upload ftp_upload s3_upload cf_upload github

content/-.md

+Title: It has arrived!
+Date: 2009-12-04 18:06
+Author: OSP
+Slug:  
+Status: draft
+
+As part of the stream of posts still on our list, let's start with this
+one

content/conversations/a-user-should-not-be-able-to-shoot-himself-in-the-foot.md

+Title: A user should not be able to shoot himself in the foot
+Date: 2007-05-19 08:05
+Author: Femke
+Category: Conversations
+Tags: LGM 2007, Scribus
+Slug: a-user-should-not-be-able-to-shoot-himself-in-the-foot
+Status: published
+
+**Interview with Andreas Vox, Scribus-developer**
+
+[![andreas.JPG](http://ospublish.constantvzw.org/blog/wp-content/uploads/andreas.thumbnail.JPG){.float}](http://ospublish.constantvzw.org/blog/wp-content/uploads/andreas.JPG "andreas.JPG")While
+in the background participants to the Libre Graphics Meeting 2007 start
+saying goodbye to each other, Andreas Vox makes time to sit down with us
+in the hotel lounge. We want to talk to him about Scribus, the
+open-source application for professional page layout. Not only as users
+that do design with it, but also because Scribus helps us think about
+links between software, free culture and design.  
+<!--more-->
+
+Andreas is a mathematician with an interest in system dynamics, who
+lives and works in Lübeck, Germany. Together with Franz Schmid, Petr
+Vanek (subik), Riku Leino (Tsoots), Oleksandr Moskalenko (malex), Craig
+Bradney (MrB), Jean Ghali and Peter Linnel (mrdocs) he forms the core
+Scribus developer team. He has been working on Scribus since 2003 and is
+currently responsible for redesigning the internal workings of its text
+layout system.
+
+Other interviews with the Scribus team:  
+<http://dot.kde.org/1096453300/>  
+<http://www.kde.me.uk/index.php?page=fosdem-interview-scribus>
+
+OSP: *This weekend Peter Linnel presented amongst many other new Scribus
+features
+\[[1](http://wiki.scribus.net/index.php/Version_1.3.4%2B_-_New_Features)\],
+The Color Wheel, which at the click of a button visualises documents the
+way they would be perceived by a colour blind person. Can you explain
+how such a feature entered into Scribus? Did you for example speak to
+accessibility experts?*
+
+A: I don't think we did. The code was implemented by subik \[Petr
+Vanek\], a developer from the Czech Republic. As far as I know, he saw a
+feature somewhere else or he found an article about how to do this kind
+of stuff, and I don't know where he did it, but I would have to ask him.
+It was a logic extension of the colour wheel functionality, because if
+you pick different colours, they look different to all people. What
+looks like red and green to one person, might look like grey and yellow
+to other persons. Later on we just extended the code to apply to the
+whole canvas.
+
+OSP: *It is quite special to offer such a precise preview of different
+perspectives in your software. Do you think it it is particular to
+Scribus to pay attention to these kind of things?*
+
+A: Yeah, sure. Well, the interesting thing is... in Scribus we are not
+depending on money and time like other proprietary packages. We can ask
+ourselves: is this useful? Would I have fun implementing it? Am I
+interested in seeing how it works? So if there is something we would
+like to see, we implement it and look at it. And because we have a good
+contact with our user base, we can also pick up good ideas from them.
+
+OSP: *There clearly is a strong connection between Scribus and the world
+of pre-press and print. So, for us as users, it is an almost
+hallucinating experience that while on one side the software is very
+well developed when it comes to pdf-export for example, I would say even
+more developed than in other applications, but than still it is not
+possible to undo a text-edit. Could you maybe explain how such a
+discrepancy can happen, to make us understand better?*
+
+A: One reason is, that there are more developers working on the project,
+and even if there was only one developer, he or she would have her own
+interests. Remember what George Williams said about FontForge...
+\[[2](http://ospublish.constantvzw.org/?p=221)\] he is not that
+interested in nice Graphical User Interfaces, he just makes his own
+functionality... that is what interests him. So unless someone else
+comes up who compensates for this, he will stick to what he likes. I
+think that is the case with all open source applications. Only if you
+have someone interested and able to do just this certain thing, it will
+happen. And if it is something boring or something else... it will
+probably not happen. One way to balance this, is to keep in touch with
+real users, and to listen to the problems they have. At least for the
+Scribus team, if we see people complaining a lot about a certain feature
+missing... we will at some point say: “come on, let's do something about
+it”. We would implement a solution and when we get thanks from them and
+make them happy, that is always nice.
+
+OSP: *Can you tell us a bit more about the reasons for putting all this
+work into developing Scribus, because a layout application is quite a
+complex monster with all the elements that need to work together... Why
+is it important you find, to develop Scribus?*
+
+A: I use to joke about the special mental state you need to become a
+Scribus developer... and one part of it is probably megalomania! It is
+kind of mountain climbing. We just want to do it, to prove it can be
+done. That must have been also true for Franz Schmid, our founder,
+because at that time, when he started, it was very unlikely that he
+would succeed. And of course once you have some feedback, you start to
+think: “hey, I can do it... it works. People can use it, people can
+print with it, do things ... so why not make it even better?”  
+Now we are following InDesign and QuarkXpress, and we are playing the
+top league of page layout applications ... we're kind of in a
+competition with them. It is like climbing a mountain and than seeing
+the next, higher mountain from the top.
+
+OSP: *In what way is it important to you that Scribus is free software?*
+
+A: Well... it would not work with closed software. Open software allows
+you to get other people that also are interested in working on the
+project involved, so you can work together. With closed software you
+usually have to pay people; I would only work because someone else wants
+me to do it and we would not be as motivated. It is totally different.
+If it was closed, it would not be fun. In Germany they studied what
+motivates open source developers, and they usually list: 'fun'; they
+want to do something more challenging than at work, and some social
+stuff is mentioned as well. Of course it is not money.
+
+OSP: *One of the reasons the Scribus project seems so important to us,
+is that it might draw in other kinds of users, and open up the world of
+professional publishing to people who can otherwise not afford
+proprietary packages. Do you think Scribus will change the way
+publishing works? Does that motivate you, when you work on it?*
+
+A: I think the success of open source projects will also change the way
+people use software. But I do not think it is possible to foresee or
+plan, in what way this will change. We see right now that Scribus is
+adopted by all kinds of idealists, who think that is interesting, lets
+try how far we can go, and do it like that. There are other users that
+really just do not have the money to pay for a professional page layout
+application such as very small newspapers associations, sports groups,
+church groups. They use Scribus because otherwise they would have used a
+pirated copy of some other software, or another application which is not
+up to that task, such as a normal word processor. Or otherwise they
+would have used a deficient application like MS Publisher to do it. I
+think what Scribus will change, is that more people will be exposed to
+page layout, and that is a good thing, I think.
+
+OSP: *In another interview with the Scribus team
+\[[3](http://www.kde.me.uk/index.php?page=fosdem-interview-scribus)\],
+Craig Bradney speaks about the fact that the software is often compared
+with its proprietary competition. He brings up the 'Scribus way of doing
+things'. What do you think is 'The Scribus Way'?*
+
+A: I don't think Craig meant it that way. Our goal is to produce good
+output, and make that easy for users. If we are in doubt, we think for
+example: InDesign does this in quite an OK way, so we try to do it in a
+similar way; we do not have any problems with that. On the other hand...
+I told you a bit about climbing mountains... We cannot go from the one
+top to the next one just in one step. We have to move slowly, and have
+to find our ways and move through valleys and that sometimes also limits
+us. I can say: “I want it this way” but then it is not possible now, it
+might be on the roadmap, but we might have to do other things first.
+
+OSP: *When we use Scribus, we actually thought we were experiencing 'The
+Scribus Way' through how it differences from other layout packages.
+First of all, in Scribus there is a lot more attention for everything
+that happens after the layout is done, i.e. export, error checking etc.
+and second, working with the text editor is clearly the preferred way of
+doing layout. For us it links the software to a more classic ways of
+doing design: a strictly phased process where a designer starts with
+writing typographic instructions which are carried out by a typesetter,
+after which the designer pastes everything into the mock-up. In short:
+it seems easier to do a magazine in Scribus, than a poster. Do you
+recognize that image?*
+
+A: That is an interesting thought, I have never seen it that way before.
+My background is that I did do a newspaper, magazine for a student
+group, and we were using Pagemaker, and of course that influenced me. In
+a small group that just wants to bring out a magazine, you distribute
+the task of writing some articles, and usually you have only one or two
+persons who are capable of using a page layout application. They pull in
+the stories and make some corrections, and then do the layout. Of course
+that is a work flow I am familiar with, and I don't think we really have
+poster designers or graphic artists in the team. On the other hand... we
+do ask our users what they think should be possible with Scribus and if
+a functionality is not there, we ask them to put in a bug report so we
+do not forget it and some time later we will pick it up and implement
+it. Especially the possibility to edit from the canvas, this will
+approve in the upcoming versions.
+
+Some things we just copied from other applications. I think Franz
+(Schmid) had no previous experience with Pagemaker, so when I came to
+Scribus, and saw how it handled text chains, I was totally dismayed and
+made some changes right away because I really wanted it to work the way
+it works in Pagemaker, that is really nice. So, previous experience and
+copying from another applications was one part of the development.
+Another thing is just technical problems. Scribus is at the moment
+internally not that well designed, so we first have to rewrite a lot of
+code to be able to reach some elements. The coding structure for drawing
+and layout was really cumbersome inside and it was difficult to improve.
+We worked with 2.500 lines of code, and there were no comments in
+between. So we broke it down in several elements, put some comments in
+and also asked Franz: “why did you did this or that”, so we could put
+some structure back into the code to understand how it works. There is
+still a lot of work to be done, and we hope we can reach a state where
+we can implement new stuff more easily.
+
+OSP: *it is interesting how the 2.500 lines of code are really tangible
+when you use Scribus old-style, even without actually seeing them. When
+Peter Linnel was explaining how to make the application comply to the
+conservative standards of the printing business, he used this term
+'self-defensive code'...*
+
+A: At Scribus we have a value that a file should never break in a print
+shop. Any bug report we receive in this area, is treated with first
+priority.
+
+OSP: *We can speak from experience, that this is really true! But this
+robustness shifts out of sight when you use the inbuilt script function;
+then it is as if you come in to the software through the back-door. From
+self-defence to the heart of the application?*
+
+A: it is not really self-defence... programmers and software developers
+sometimes use the expression: 'a user should not shoot himself in the
+foot'. Scribus will not protect you from ugly layout, if that would be
+possible at all! Although I do sometimes take deliberate decisions to
+try and do it ... for example that for as long as I am around, I will
+not make an option to do 'automatic letter spacing', because I think it
+is just ugly. If you do it manually, that is your responsibility; I just
+do not feel like making anything like that work automatically. What we
+have no problems with, is to prevent you from making invalid output. If
+Scribus thinks a certain font is not OK, and it might break on one or
+two types of printers ... this is reason enough for us to make sure this
+font is not used. The font is not even used partially, it is gone. That
+is the kind of self-defence Peter was talking about. It is also how we
+build pdf-files and postscript. Some ways of building postscript take
+less storage, some of it would be easier to read for humans, but we
+always take an approach that would be the least problematic in a print
+shop. This meant for example, that you could not search in a pdf \[OSP:
+because the fonts get outlined and/or reencoded\]. I think you can do
+that now, but there are still limitations; it is on the roadmap to
+improve over time, to even add an option to output a web oriented pdf
+and a print oriented pdf ... but it is an important value in Scribus is
+to get the output right. To prevent people to really shoot themselves in
+the foot.
+
+OSP: *Our last question is about the relation between the content that
+is layed-out in Scribus, and the fact that it is an open source project.
+Just as an example, Microsoft Word will come out with an option to make
+it easy to save a document with a Creative Commons License
+\[[4](http://creativecommons.org/press-releases/entry/5947)\]. Would
+this, or not, be an interesting option to add to Scribus? Would you be
+interested in making that connection, between software and content?*
+
+A: It could well be we would copy that, if it is not already been
+patented by Microsoft! To me it sounds a bit like a marketing trick ...
+because it is such an easy function to do. But, if someone from Creative
+Commons would ask for this function, I think someone would implement it
+for Scribus in a short time, and I think we would actually like it.
+Maybe we would generalize it a little, so that for example you could
+also add other licenses too. We already have support for some meta data,
+and in the future we might put some more function in to support license
+managing, for example also for fonts.
+
+About the relation between content and OSS software in general... there
+are some groups who are using Scribus I politically do not really
+identify with. Or more or less not at all. If I meet those people on the
+IRC chat, I try to be very neutral, but I of course have my own thoughts
+in the back of my head.
+
+OSP: *Do you think using a tool like Scribus produces a certain kind of
+use?*
+
+A: No. preferences for work tools and political preference are really
+orthogonal, and we have both. For example when you have some right wing
+people they could also enjoy using Scribus and socialist groups as well.
+It is probably the best for Scribus to keep that stuff out of it. I am
+not even sure about the political conviction of the other developers.
+Usually we get along very well, but we don't talk about those kinds of
+things very much. In that sense I don't think that using Scribus will
+influence what is happening with it.
+
+As a tool, because it makes creating good page layouts much easier, it
+will probably change the landscape because a lot of people get exposed
+to page layout and they learn and teach other people; and I think that
+is growing, and I hope it will be growing faster than if it is all left
+to big players like InDesign and Quark... I think this will improve and
+it will maybe also change the demands that users will make for our
+application. If you do page layout, you get into a new frame of mind...
+you look in a different way at publications. It is less content
+oriented, but more layout oriented. You will pick something up and it
+will spread. People by now have understood that it is not such a good
+idea to use 12 different fonts in one text... and I think that knowledge
+about better page layout will also spread.  
+  
+  
+  
+  
+  
+  
+  
+  
+\[1\]
+[http://wiki.scribus.net/index.php/Version\_1.3.4%2B\_-\_New\_Features](a%20href=)  
+\[2\] <http://ospublish.constantvzw.org/?p=221>  
+\[3\] <http://www.kde.me.uk/index.php?page=fosdem-interview-scribus>  
+\[4\] <http://creativecommons.org/press-releases/entry/5947>

content/conversations/etapes-220.md

+Title: étapes 220
+Date: 2014-09-29 12:44
+Author: Colm
+Category: Conversations, News, Texts, Works
+Tags: étapes, co-working, Interview, libreobjet
+Slug: etapes-220
+Status: published
+
+*étapes* magazine issue 220 focused on Co-Working, so we were pleased to