chat.freenode.net #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 : doc.tryton.org/1.4/trytond/doc/reports.html | ||
2012-12-21 06:55 -!- calbasi(~joan@14.66.14.37.dynamic.jazztel.es) has left #tryton | ||
2012-12-21 09:16 <rmu> iamnoob: up to date docs are here http://doc.tryton.org/2.6/trytond/doc/topics/reports/index.html | ||
2012-12-21 09:16 <rmu> iamnoob: what do you want to accomplish? | ||
2012-12-21 18:56 -!- calbasi(~joan@14.66.14.37.dynamic.jazztel.es) 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 irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!