| <<<Back 1 day (to 2016/09/19) | 20160920 |
ski7777 | hi | 10: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.svg | 14:04.28 |
tor8 | let's see if I can get my tests_private git repo to sync | 14:07.38 |
| I downloaded the tarball just before I went on vacation | 14: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 bah | 14: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 yet | 14:19.30 |
Robin_Watts | Well, that's a good reason. | 14:19.48 |
tor8 | we only support vector art | 14:20.16 |
| no images, no text | 14:20.21 |
| the big #if 0 in svg_run_element | 14:20.32 |
Robin_Watts | Is that present in the gs version? | 14:21.15 |
tor8 | I don't think so | 14:25.43 |
| this is copied straight from the gs version and has some more fixes | 14:26.00 |
| and I believe the gs version has been purged from the source tree, due to not being maintained | 14: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 parser | 14:31.08 |
kens | ah yeah, that got pulled. Buggy, nobody preparted to work on it, and no demand for it | 14: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 GS | 14:32.29 |
sebras | tor8: http://bugs.ghostscript.com/show_bug.cgi?id=697106 | 15: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 setup | 15: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 | hmm | 16: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)>>> | |