Commit 07fecf80 authored by colm's avatar colm
Browse files

a backup or an export or a migration

parents
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
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
This diff is collapsed.
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
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>
This diff is collapsed.
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