hello from brussels! lo hi femke hi pierre, you asked about the tiffs we are loading -- it is one at a time and we tried first with jpgs and this doesn't make a difference for speed. snelting: It’s just that you load them in a loop & I don’t know if they are actually "unloaded" at some point what a TOP gives? |<-- ludo has left freenode (Read error: 104 (Connection reset by peer)) ah. (i'm a python absolute beginner) 6336 snelting 25 0 398m 156m 13m R 99 16.1 593:33.01 scribus -->| sjc (n=sjc@78.32.104.102) has joined #scribus wait... that's 99% cpu for scribus ;-) normal It works after all ;) yes, for almost 12 hours! (still running ... at number 310 now. impressing) impressive i meant * sjc drops in to follow the "Testing Scribus Limits" discussion -->| ludo (n=ludo@118.10.101-84.rev.gaoland.net) has joined #scribus hi snelting hello! From what you wrote, I understand tyhat scribus generates some garbage somewhere which it in turn takes long time to process, but where? its still a question! I didn't say garbage! ;-) |<-- Okona has left freenode (leguin.freenode.net irc.freenode.net) |<-- Wed has left freenode (leguin.freenode.net irc.freenode.net) |<-- ben_goodger has left freenode (leguin.freenode.net irc.freenode.net) it is still relatiely fast, but with 200 more runs to go... what do you think? will scribus make it to the end? -->| ben_goodger (n=ben@host86-146-18-220.range86-146.btcentralplus.com) has joined #scribus -->| Wed (n=Wed@83.209.33.104) has joined #scribus -->| Okona (n=Okona@macrbg1.informatik.tu-muenchen.de) has joined #scribus i mean... i think we have a bit of extra time so if it means waiting than we will just be patient cool Although there’s something that looks like a memory leak here but it would be tragic if the process stops at 498... yes, something is leaking or clogging up has anything been concluded in the code yet before I arrived? I did not like those LoadImage lines when I quickly glanced through the source Oh, for 2 covers, you can trick it by making them by hand :D good thinking ... duh Printer deadline postoned is the fix for now sjc! pierremarc: oic :) so i should look for some kind of 'unloading' in the script? is scribus memorizing all former 298 docs you think? that would be really amazing! I don’t think so I’ll try to reproduce it to see ok, i can upload the folder structure with the first 5 elements plus .sla? Oh, it would be great ok give me a few minutes it is great to have you look at it -- by now getting really curious about what is going on -->| Asynchronicle (n=Asynchro@68.244.193.82.ediscom.de) has joined #scribus ok, it should be ok -- i don't dare to launch another scribus to test right now... I will :) http://ospublish.constantvzw.org/sources/pzicatalogue Title: Index of /sources/pzicatalogue (at ospublish.constantvzw.org) so now you should be able to generate up to 5 catalogues (at cover no. 324 now) snelting: sorry to bother you but, can you zip or tar or whatever to get it all in only one archive? It will ease the download a lot ok you are right sorry! there! http://ospublish.constantvzw.org/sources/pzicatalogue/cataloguemachine.zip c’est parti !!! -->| Cymek (n=Cymek__@p4FF65D06.dip.t-dialin.net) has joined #scribus tell me if you are missing anything? it complains about missing images, but I"ll modify it ok, shouldn't make a difference to leakage or clogging ;-) |<-- Asynchronicle has left freenode ("left") |<-- Herm has left freenode (Read error: 110 (Connection timed out)) snelting: checking the script & material to change things I see that gordo’s images are in fact PDFs, why? hmmm. good question. all material comes from different art projects; this is how he generated it and we have left it that way after testing with the printer. not elegant, i admit he = gordo ok also, we were interested in working with many different source materials -- each of the graduates in the catalogue has found a way to add something to each of the 500 covers the 'lettriste' you see in the python script is one of them, randomly changing letter sizes well, it’s cool but if it ends up to be an issue, might be interesting to first convert all to an unique file type, no? * pierremarc is still so slow at typing :) yes. if we need to we will do it of course. the placed pdf is a bit silly especially because it is three giant pixels (if you put all catalogues together, it forms an image) scribus still holding out well... at no. 332 now <--| JanH has left #scribus -->| JanH (n=joerg@Pb614.p.pppool.de) has joined #scribus <--| JanH has left #scribus pierre: ça va? i will need to go out for a few hours I monitor the script now leaving the catalogue machine running on its own how do you monitor? Right now just with timers. Want to reproduce your issur first ok. i'm just looking at the difference of the writing time of the files Images(0) loaded in 1.46746706963 PDF(0) saved in 22.6262660027 Images(1) loaded in 1.37868094444 PDF(1) saved in 22.6658248901 Images(2) loaded in 1.39984512329 PDF(2) saved in 21.3724861145 Images(3) loaded in 1.52945899963 PDF(3) saved in 22.4700379372 Images(4) loaded in 1.68279314041 PDF(4) saved in 24.7134678364 so... this means between 22 and 24 secs? yes hmm so it does go up, but don't know what you can tell from 5 runs sorry to have to leave now in the middle of the detective np I will be here at least tonight ok, me too thanks for a first look! de rien, le projet a l’air sympa LATER.... good news -- just finished pdf nr. 500 nice ... i mean; so scribus has worked for 23 hours non-stop really, cause i was going to bed :) hihi. so interesting is, that it did not slow down much more i will go through the script with some people in the coming days to see what can be done better (for the next time ;-)) were the same fonts used for all pages? yes. ie, for all docs, or different ones for some of the front covers/ ? the inside is identical for each book; the cover has our own notcourier-sans only inside is manually generated k we had problems earlier, because of a corrupt font. 'manually' generated pages (from scribus, selecting 'export as pdf' manually) |<-- jghali has left freenode ("Parti") yeah would automatically detect the problem and outline it -->| jghali (n=jghali@ANantes-157-1-159-93.w86-195.abo.wanadoo.fr) has joined #scribus =-= Mode #scribus +o jghali by mrscribe but the python generated pdf embedded it / tried to deal with it and that made huge files that made the printers pre-flight checker crassh! -->| hawk_pdm (n=robert@dslb-088-072-238-036.pools.arcor-ip.net) has joined #scribus so, that was a good lesson. it shouldnt have been any different in theory hm luckily its getting a rewrite with GSoC i am looking forward! combined with POD the scripter really makes a difference -->| JanH (n=joerg@Pb614.p.pppool.de) has joined #scribus our experiments are a bit brutal now hehe but we need to start somewhere ;-) ok, i'll go over the script with some people and post back about what we find on our side ok thanks snelting: hi femke hello! btw, it looks like amsterdam is the leading candidate for LGM so far yes i saw if it is going to go through, there is many people i should connect lgm to it is a bit lazy option for me / us but it could work out well if lgm lands in the land of design ;-) i am not a good organiser but i will do what i can to help :) if it is final, amsterdam it will be on the create list? the create list is used for lgm organisation, yes, so you will see it there ok. i'm already looking out for things -- for sure the piet zwart institute (the org we did the 500 cover catalogue for) can be helpful i'll gather my notes thanks again, and pierre: sleep well!