a backup or an export or a migration

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

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>