Log of #ghostscript at irc.freenode.net.

Search:
 <<<Back 1 day (to 2016/09/19)20160920 
ski7777 hi10:22.54 
ghostbot Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line.10:22.54 
sebras Robin_Watts: hm... I'm surprised I cannot see the signed/unsigned warnings using gcc/clang..?13:50.31 
  tor8: do we consciously disable those?13:50.55 
Robin_Watts sebras: They won't show up on 64bit linux.13:54.57 
  (probably)13:55.05 
sebras Robin_Watts: I'm on 32bit though.13:55.40 
tor8 Robin_Watts: where do I find 410.svg?14:02.57 
Robin_Watts tests_private/svg/w3-docs/410.svg14:04.28 
tor8 let's see if I can get my tests_private git repo to sync14:07.38 
  I downloaded the tarball just before I went on vacation14:07.49 
  but didn't have time to unpack it and get it working. had to install another hard drive.14:08.06 
  error: packfile .git/objects/pack/pack-c597f758da3c11fdfa7b907c3da6170538ffabca.pack does not match index bah14:09.51 
Robin_Watts You could just grab /home/regression/cluster/tests_private.git/svgs/w3-docs/ from casper.14:13.43 
  s/svgs/svg/ I think, sorry.14:14.00 
tor8 Robin_Watts: yeah, we don't support <text> elements in our SVG parser yet14:19.30 
Robin_Watts Well, that's a good reason.14:19.48 
tor8 we only support vector art14:20.16 
  no images, no text14:20.21 
  the big #if 0 in svg_run_element14:20.32 
Robin_Watts Is that present in the gs version?14:21.15 
tor8 I don't think so14:25.43 
  this is copied straight from the gs version and has some more fixes14:26.00 
  and I believe the gs version has been purged from the source tree, due to not being maintained14:26.36 
kens gdevsvg ?14:27.30 
  THe SVG outptu device ?14:27.35 
  Or the SVG parser ?14:27.50 
tor8 kens: the svg parser14:31.08 
kens ah yeah, that got pulled. Buggy, nobody preparted to work on it, and no demand for it14:31.34 
tor8 kens: yes. we pulled it into mupdf instead, where it'll be needed for EPUB illustrations.14:31.58 
kens Well, I guess if you ever fixed up the bugs we could port it back, if anyone exhibited interest in it for GS14:32.29 
sebras tor8: http://bugs.ghostscript.com/show_bug.cgi?id=69710615:10.12 
  tor8: it fails in ftoa.c on line 181 because the constant is 64 bit, right.15:10.37 
  tor8: seems like his compiler headers are broken somehow?15:10.50 
  I'm compiling on 32-bit and it works well for me.15:10.58 
  tor8: I'm inclined to close the bug with a comment stating that uint64_t must be defined to be 32 bit regardless of int/long size on any arch and it works well for us..?15:12.04 
tor8 you mean 64-bit?15:15.36 
  I think he's got a bad environment setup15:15.50 
sebras tor8: yes, me too.15:16.03 
  tor8: and yes, 64-bit.15:16.15 
  if uint64_t isn't 64-bit, then what can we do?15:16.48 
tor8 nothing. it *must* be 64-bit.15:19.29 
sebras tor8: my feelings exactly, and it would be nice to get rid of an easy bug. :)15:21.31 
  care to continue the conversaion with him and close it?15:21.49 
  or do you want me to?15:21.51 
tor8 sebras: be my guest :)15:23.24 
  ask for clarification, if he doesn't come up with one, let's just close it as WORKSFORME.15:23.39 
mvrhel_laptop hmm16:25.56 
jogux sebras: tor8: on that gcc "integer constant is too large" thing, I think I ran into something very similar (not on mupdf) a while back, have a feeling adding UINT64_C(...) around the constant solved it. I think it's gcc incorrectly assuming the type a literal constant is, but I have no idea what the C standard says in this area.17:04.08 
 Forward 1 day (to 2016/09/21)>>> 
ghostscript.com
Search: