IRC logs of #tryton for Friday, 2012-12-21 #tryton log beginning Fri Dec 21 00:00:01 CET 2012
2012-12-21 05:13 <iamnoob> hi good day, can anybody please teach me how i can do sa sample printing in tryton? im using open office. i cant understart well the guide here :
2012-12-21 06:55 -!- calbasi( has left #tryton
2012-12-21 09:16 <rmu> iamnoob: up to date docs are here
2012-12-21 09:16 <rmu> iamnoob: what do you want to accomplish?
2012-12-21 18:56 -!- calbasi( has left #tryton
2012-12-21 23:25 <odicha> Hi all!
2012-12-21 23:27 <odicha> I'm testing unoconv with tryton server on win32 and I have a strange failure. When I call unoconv from tryton (converting odt to pdf) output file is corrupt in some way.
2012-12-21 23:27 <odicha> it has about sixty bytes more than a valid pdf. adobe reader fails to open it
2012-12-21 23:28 <odicha> libreoffice opens it but it has no text
2012-12-21 23:29 <odicha> I think it could be some kind of error between unoconv & libreoffice but I'm not sure
2012-12-21 23:29 <odicha> some idea??
2012-12-21 23:31 <rmu> odicha: does unoconv work without tryton?
2012-12-21 23:33 <odicha> sure!
2012-12-21 23:34 <odicha> rmu: if I run unoconv from command line with same file it converts the file ok
2012-12-21 23:34 <rmu> strange
2012-12-21 23:34 <odicha> rmu: if I run from within tryton server it fails. output is about 60 bytes bigger and unreadable
2012-12-21 23:35 <odicha> rmu: header and EOF are there instead.
2012-12-21 23:35 <rmu> is it completely different or only the appended 60 bytes?
2012-12-21 23:36 <odicha> rmu: body is different, comparing byte to byte
2012-12-21 23:36 <odicha> and it outputs a malformed pdf
2012-12-21 23:36 <rmu> hmm. no idea
2012-12-21 23:36 <odicha> rmu: neither me, it seems to be out of tryton scope, but not sure
2012-12-21 23:37 <odicha> rmu: under windows unoconv must be in program path of libreoffice and must be called from libreoffice python
2012-12-21 23:37 <rmu> you could try finding the place where tryton calls unoconv, and examine the temp files generated there
2012-12-21 23:37 <odicha> yeah i've done
2012-12-21 23:39 <odicha> rmu: I'm trying make it works under windows for opening a feature bug... now is the only feature that doesn't work on in32
2012-12-21 23:39 <rmu> on linux i would strace the tryton server... on windows: sysinternals tools?
2012-12-21 23:39 <odicha> on windows I use eclipse + pydev for python & processmon from sysinternals
2012-12-21 23:39 <odicha> it does all ok
2012-12-21 23:40 <odicha> but the output file is not right. I think about some error on --stdout modifier in unoconv
2012-12-21 23:40 <odicha> perhaps on win32 it "gets mad"
2012-12-21 23:40 <rmu> perhaps LF gets converted to CRLF?
2012-12-21 23:41 <rmu> can you try to search/replace with a binary-aware editor?
2012-12-21 23:41 <odicha> not sure. in a 10k pdf the size changes about 60 bytes
2012-12-21 23:41 <odicha> hexeditor of course :)
2012-12-21 23:41 <odicha> no sucess
2012-12-21 23:42 <rmu> --stdout on the commandline does work?
2012-12-21 23:42 <odicha> th strange thing.... when file is created from command line... after EOF has one byte
2012-12-21 23:42 <odicha> when file is created from tryton it has two bytes
2012-12-21 23:43 <odicha> so perhaps there's some kind of mangling around it
2012-12-21 23:43 <rmu> what do you mean "after EOF"?
2012-12-21 23:43 <odicha> more testing needed
2012-12-21 23:43 <odicha> if you open a pdf file in raw mode, you'll see an EOF at then end of file, and one byte
2012-12-21 23:44 <odicha> thats the pdf format #END#
2012-12-21 23:44 <odicha> but when I run unoconv from tryton it has two bytes instead one after EOF
2012-12-21 23:45 <odicha> I'm thinking about testing calling UNO direct from tryton, so I can try to isolate error...
2012-12-21 23:46 <odicha> no many people calls unoconv from another python instance on windows
2012-12-21 23:46 <odicha> it can be one of a lot of possible errors
2012-12-21 23:47 <rmu> i see linefeed (0x0a) after "EOF" in the PDF
2012-12-21 23:47 <odicha> ok
2012-12-21 23:47 <odicha> in tryton + unoconv generated pdf there are two bytes
2012-12-21 23:47 <odicha> let me see
2012-12-21 23:48 <odicha> 45 4f 46 0d 0a
2012-12-21 23:48 <odicha> cr + lr ??
2012-12-21 23:49 <odicha> EOF LF CR ??
2012-12-21 23:49 <odicha> oh my god... welcome to nigntmare :)
2012-12-21 23:49 <rmu> there should not be CR (0x0d), ony LF (0x0a) IMHO
2012-12-21 23:50 <odicha> ok
2012-12-21 23:50 <odicha> CR LF
2012-12-21 23:50 <odicha> but it's wrong
2012-12-21 23:51 <odicha> lot of 0d 0as
2012-12-21 23:52 <odicha> two python talking... one in LF & other in CR+LF ?? perhaps that's the start of all... I'm going to test dumping file instead of using --stdout
2012-12-21 23:53 <rmu> i don't know for sure, but probably the stdin/stdout (to the extent such a thing exists in windows) probably is opened in "text" mode in python
2012-12-21 23:53 <odicha> it's possible
2012-12-21 23:55 <odicha> I'll do some tests tonight... if there's some luck I'll make a preliminary patch... anyway I think I'm 100% of potential win32 tryton server testers :)
2012-12-21 23:57 <rmu> hmm. python doc has something to say about subprocess.Popen and "universal_newlines"
2012-12-21 23:58 <odicha> :) I was reading it now...

Generated by 2.17.3 by Marius Gedminas - find it at!