[Scribus] Differences between startup script and regular
Yegor Jbanov
yegor.jbanov
Sat Dec 8 04:44:11 CET 2007
Craig,
Thanks for the response. Everything happened exactly as you suggested.
I was indeed doing some real work in the script without waiting for
Scribus to fully start up, or rather the script used the current
thread for HTTP server and did not allow Scribus to finish
initialization. A Qt hook on "appStarted" solved the problem. Although
it would be nice if Scribus responded with a more friendly reaction,
maybe a ScribusException thrown into the script with explanation.
Crashing with a core dump doesn't seem to be friendly at all.
Thanks a lot.
Yegor
On Dec 7, 2007 4:00 AM, <scribus-request at nashi.altmuehlnet.de> wrote:
> Send Scribus mailing list submissions to
> scribus at nashi.altmuehlnet.de
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://nashi.altmuehlnet.de/mailman/listinfo/scribus
> or, via email, send a message with subject or body 'help' to
> scribus-request at nashi.altmuehlnet.de
>
> You can reach the person managing the list at
> scribus-owner at nashi.altmuehlnet.de
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Scribus digest..."
>
>
> Today's Topics:
>
> 1. Re: Some ideas, and some clarifications maybe. (Hal V. Engel)
> 2. Differences between startup script and regular script
> (Yegor Jbanov)
> 3. Re: Differences between startup script and regular script
> (Craig Ringer)
> 4. date on page (martin mckenna)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 6 Dec 2007 11:39:04 -0800
> From: "Hal V. Engel" <hvengel at astound.net>
> Subject: Re: [Scribus] Some ideas, and some clarifications maybe.
> To: scribus at nashi.altmuehlnet.de
> Message-ID: <200712061139.04918.hvengel at astound.net>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Wednesday 05 December 2007 19:32:49 Richard wrote:
> > Here is when my bad english becomes an obstacle, i dont know what you
> > mean about this part.
> >
> > > All video cards have that capability (a colour look up table or LUT),
> > > but I've never seen one that exposes it directly to the user before. You
> > > normally have to load data generated by a profiling tool instead.
> >
> > On nvidia i have a colour correction panel and a slider for every color
> > channel, maybe it's not professional, or as much accurate as it should
> > but you can change R, G, and B channels individually on gamma contrast
> > and brightness levels, it can also load an ICM or ICC profile.
> > I may not know as much as you on colour management, profiling, printing
> > or maybe not understand english too good, but i do know i can make my
> > screen become out of any color at all.... (or full) and believe me, it
> > is awful...
> > My monitor, a 21" Sony Trinitron has a channel by channel adjustment
> > too, among other stuff. And, if you put a colours sample or scale on
> > screen you can see only some of them changing, remember screen is red,
> > green and blue, so you can see cyan changing while moving on red slider,
> > but not blue and so on.
> > Probably if you're using a ndivia card you don't have coolbits enabled,
> > you may give it a try.
> > I repeat, i may not know as much as you on this subject but i do know i
> > can handle colours so much by hand. Off course, color profiles installed
> > or hand-tweaking is not the same. But i can have an approach to MY home
> > printing colours at least, and with some patience maybe also a print
> > shop approach, not 100% but as much as an eye allows. Repeating again,
> > it may became insane to adjust like this, but when everything else is
> > missing.....
> > Best greetings...
>
> Of course, you can make all kinds of adjustments to the video card and the
> monitor. But as Craig pointed out you are doing this using your eyes
> (actually your eyes and mind) and how you perceive (this is the mind part)
> colors is highly dependant on your surroundings. In other words if the
> lighting changes in your viewing area and you readjust your monitor you will
> likely come out with a totally different result (So which result
> is "correct"? Are either of them "correct"?). In other words the result is
> subjective rather than objective and you want to eliminate as much
> subjectivity in this process as possible.
>
> The Sony monitors are actually very good and all of them I have looked at
> (this is only a few so there may be exceptions) have more adjustments
> available than most monitors. For example these have the normal RGB gain
> controls to set your white point (IE. color balance of the brighter tones)
> like most monitors. And, unlike most monitors, these also have RGB offset
> controls (probably labeled as RGB brightness controls) that will allow you to
> set your black point (IE. the color balance of the darker tones).
>
> With a measurement device like a Huey or an EyeOne Display 2/Lt and software
> like LProf or ArgyllCMS these adjustments (RGB gain and RGB offset) can be
> set to be with in +-50K of 6500K (or some other value like 5000K). This can
> be repeated every time these tools are used to make these adjustments no
> matter what kind of light is present in the room (the Huey should be used in
> a darkened room because it does have issues with light leakage). You will
> end up with a result that is objective and not subjective. In addition,
> tools like this make it possible to remove non-linearity's from the the
> displays response curves which is something you can NOT do using the video
> card and monitor controls. The correction of non-linearity's is what Craig
> was writing about when he wrote "All video cards have that capability (a
> colour look up table or LUT), but I've never seen one that exposes it
> directly to the user before. You normally have to load data generated by a
> profiling tool instead." He was correct about this.
>
> A few years ago when this measurement hardware started at about $300 US it
> was easy to understand why people were reluctant to purchase this hardware
> since it was by almost any standard expensive. But nowdays using open source
> software and purchasing the hardware discounted on the net you can do this
> for about $60 US. If you are doing color critical work and are spending any
> amount of money either printing on your own printers (after all ink, paper
> and wear and tear on the printer are not cheap) or having things printed by a
> print shop spending $60 to have your monitor correctly calibrated and
> characterized is actually a cheap investment since you will likely save that
> much in short order because of reduced printing costs (IE. fewer proofs
> needed or fewer wasted prints if you do this at home).
>
> I should add that I am not saying that it is not possible to make things
> better if you carefully do a subjective visual adjustment of you monitor
> controls and the video card controls as compared to making no adjustments at
> all. Rather my point is that measurement hardware and the related software
> will ALWAYS get you significantly better results and it will do this in a
> much more consistant, repeatable way and will remove all subjectivity from
> the process. Frankly I was surprised by how much better my results were when
> I moved from using subjective visual methods to using measurement hardware
> and I think you will be as well. But I suspect that you will remain
> unconvinced until you actually get a chance to see this for yourself.
>
> Hal
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 6 Dec 2007 23:28:37 -0700
> From: "Yegor Jbanov" <yegor.jbanov at gmail.com>
> Subject: [Scribus] Differences between startup script and regular
> script
> To: scribus at nashi.altmuehlnet.de
> Message-ID:
> <826acced0712062228y6d6468d2md4a51ec3a2c97e38 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>
> What is the difference between running a Scripter script during
> startup and running the same script using the Script menu?
>
> I am running Scribus 1.3.3.8 on Ubuntu 7.04, GhostScript 8.15.4.
>
> I wrote a script which embeds a simple HTTP server into Scribus
> (BaseHTTPServer provided with standard Python). When I run it from the
> menu it works. I can access the server from the browser and the server
> can access Scribus API and generate output from my documents.
>
> When I run it as a startup script Scribus crashes with a message
> "Scribus crashes due to Signal #11" upon the first HTTP request from
> the browser.
>
> Here's the console output:
>
> Scribus Crash
> -------------
> Scribus crashes due to Signal #11
> Calling Emergency Save
> Saving: /tmp/scribus-server/serverpI2QPI/processors/invProc/invoice.sla.emergency
> Segmentation fault (core dumped)
>
> (remind me again where does the core gets dumped so I could analyze it?)
>
> I am not sure where exactly it crashes in my Python code. I will
> investigate further. As you see it tries to save the document I open
> for this particular HTTP request, so it must be somewhere after the
> document is opened. I suspect it has something to do with PDF export.
> (BTW, don't pay attention to the /tmp/scribus-server/... folders.
> These have nothing to do with Scribus. I create these myself.)
>
> Here's the piece of code I am running (note again, it works when I run
> it manually from the menu):
>
> # Location of the current sources
> (srcLocation, scriptFile) = os.path.split(__file__)
>
> # Open Scribus document
> scribus.openDoc(srcLocation + '/invoice.sla')
>
> # Save as PDF first
> pdfFilePath = workDir + '/invoice.pdf'
> pdf = scribus.PDFfile()
> pdf.file = pdfFilePath
> pdf.save()
>
> # Package up the result into a deliverable file
> if (isPreview):
> # Convert PDF to PPM
> ppmFilePref = workDir + '/invoice'
> ppmCommand = 'pdftoppm -f 1 -l 1 ' + pdfFilePath + ' ' + ppmFilePref
> os.popen(ppmCommand)
> # Convert PPM to JPG
> Image.open(ppmFilePref + '-000001.ppm').save(resultFile)
> else:
> # Zip the contents into the resultFile
> archive = zipfile.ZipFile(resultFile, 'w')
> archive.write(pdfFilePath)
> archive.close()
>
> # Close Scribus template document
> scribus.closeDoc()
>
> Any pointers will be appreciated.
>
> Thanks,
>
> Yegor
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 07 Dec 2007 16:28:37 +0900
> From: Craig Ringer <craig at postnewspapers.com.au>
> Subject: Re: [Scribus] Differences between startup script and regular
> script
> To: scribus at nashi.altmuehlnet.de
> Message-ID: <4758F625.5030507 at postnewspapers.com.au>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Yegor Jbanov wrote:
> > Hi,
> >
> > What is the difference between running a Scripter script during
> > startup and running the same script using the Script menu?
>
> A startup script is run once when the scripter loads, and runs as an
> extension script so it can use PyQt etc.
>
> Startup scripts were put in place to make it possible to load Python
> based extensions to Scribus automatically.
>
> Note that the startup script runs when the Python interpreter loads.
> This is well before the main window exists. A Qt signal, appStarted(),
> is emitted when startup is complete. You can only get this signal with
> PyQt; there is no hook mechanism provided in the scripter to invoke any
> arbitrary Python function on the signal. It wouldn't be too hard to
> write a C++ scripter function to set such a handler function and invoke
> it on appStarted().
>
> A PyQt example showing how to handle the appStarted() hook can be found
> in plugins/scriptplugin/samples/startup_hook.py .
>
> As a side note, appStarted() and other "hookable" signals should
> probably be processed as deferred signals in the event loop in 1.3.5 .
> This would help solve problems with reentrancy and make more
> functionality safe to invoke from hook-triggered Python functions.
>
> > I wrote a script which embeds a simple HTTP server into Scribus
> > (BaseHTTPServer provided with standard Python). When I run it from the
> > menu it works. I can access the server from the browser and the server
> > can access Scribus API and generate output from my documents.
> >
> > When I run it as a startup script Scribus crashes with a message
> > "Scribus crashes due to Signal #11" upon the first HTTP request from
> > the browser.
>
> Any chance you're trying to do real work before Scribus has fully
> started up?
>
> > Here's the console output:
> >
> > Scribus Crash
> > -------------
> > Scribus crashes due to Signal #11
> > Calling Emergency Save
> > Saving: /tmp/scribus-server/serverpI2QPI/processors/invProc/invoice.sla.emergency
> > Segmentation fault (core dumped)
> >
> > (remind me again where does the core gets dumped so I could analyze it?)
>
> Rather than analysing a core, you are usually better off running Scribus
> under gdb.
>
> gdb --args /path/to/scribus
> (gdb) run
>
>
> when Scribus crashes, it'll appear to "freeze" instead of displaying a
> crash handler dialog. The gdb prompt will show up in the terminal you're
> running gdb from, and you can explore the state of the program from there.
>
> You'll want a version of Scribus built with debug symbols (
> -DCMAKE_BUILD_TYPE=debug ) to get much information out of a debugging
> session, though.
>
> > I am not sure where exactly it crashes in my Python code. I will
> > investigate further.
>
> A backtrace would be really helpful. Run Scribus under `gdb' as
> described above and when it crashes, run the `bt' command:
>
> (gdb) bt
>
> then post the crash message from gdb (the bit near "Program received
> signal SIGSEGV, Segmentation Fault") and the output of the `bt' command.
>
> --
> Craig Ringer
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 06 Dec 2007 17:28:06 +0000
> From: martin mckenna <martinmckenna at roytrumps.com>
> Subject: [Scribus] date on page
> To: scribus at nashi.altmuehlnet.de
> Message-ID: <47583126.8000802 at roytrumps.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi
>
> I am designing an events book . and i am wondering if there is a simply
> way of getting each page with a date on it . A bit like what the
> calender script does , but each page is a day .
>
> kind regards
>
> martin mckenna
>
>
> ------------------------------
>
> _______________________________________________
> Scribus mailing list
> Scribus at nashi.altmuehlnet.de
> http://nashi.altmuehlnet.de/mailman/listinfo/scribus
>
>
> End of Scribus Digest, Vol 58, Issue 13
> ***************************************
>
More information about the scribus
mailing list