| | <<<Back 1 day (to 2016/08/22) | 20160823 |
| fredross-perry | sebras - are you about? | 01:59.03 |
| | sorry - you may be sleeping. When you get a chance, take a look at the mupdf java viewer. I cracks up in mupdf_native.c at line 470, trying to get the fields for TextBlock's bbox. This works fine in Android but not desktop. | 02:01.57 |
| | sebras - never mind. I figured it out. Android seems more forgiving about JNI signatures. | 02:21.54 |
| sebras | fred (for the logs): yeah I was asleep, sorry. but good that the issue was easy to resolve! :) | 05:36.10 |
| hj | i have a question about the parsing of the embedded font files in a pdf. is this code endian specific? | 08:19.25 |
| kens | THat depends what exactly you mean, and which kind of font you are referring to | 08:19.49 |
| hj | for an example file on Linux it works well...but on Solaris it results in: Error: can't process embedded font stream | 08:20.12 |
| kens | What is 'it' ? | 08:20.25 |
| hj | the font is a truetype font | 08:20.32 |
| kens | Yes but 'it' results in an error, what is 'it' ? The application I assume | 08:20.52 |
| hj | well gs <pdf> works fine on linux. gs <pdf> on Solaris gives errors | 08:21.04 |
| kens | OK it would be helpful to say that...... | 08:21.15 |
| chrisl | Same gs version on both? | 08:21.23 |
| hj | yes | 08:21.29 |
| kens | Are the two versions of Ghostscript the same ? WHere did you get them, what is the version ? | 08:21.33 |
| hj | 9.19 | 08:21.35 |
| | compiled them my self...it could be compiler bug as well | 08:21.54 |
| kens | Unlikely to be a compiler bug, GS is known to work on both systems, did you use gcc for both ? | 08:22.15 |
| hj | for solaris I am not sure...I need to check which compiler was detected during configure | 08:22.56 |
| | on Linux gcc | 08:23.01 |
| kens | If you are building from source it might be worthwhile picking up the latest source from Git and trying that | 08:23.08 |
| | Though I can't think of any likely fixes recently | 08:23.23 |
| | Can you make the PDF available ? | 08:23.32 |
| | Because its going to help a lot to be able to see it, otherwise we're fumbling in the dark | 08:23.50 |
| hj | I understand. | 08:24.00 |
| | I will do somemore checks and put it in the bug reports | 08:24.27 |
| | with a pdf | 08:24.35 |
| | thanks for now | 08:24.40 |
| kens | Did you open a bug report ? I haven't seen one yet | 08:24.42 |
| hj | no there is no bug report yet. | 08:24.57 |
| kens | OK | 08:25.01 |
| chrisl | hj: I just tried a file with embedded TTFs on my PPC/Linux machine, and it didn't throw any errors. | 08:25.50 |
| hj | My guess was that I could be an endian problem...but Solaris is big endian linux litte..so that why I asked it the parsing of the embedded font is endian specific | 08:26.00 |
| kens | Well *wnything* could be endian-specific | 08:26.37 |
| chrisl | PPC/Linux is big endian | 08:26.39 |
| hj | oke I will check the Solaris build. and try both gcc and c99 it both fail I will add a bug report | 08:26.47 |
| chrisl | Hence why I tried it | 08:26.49 |
| kens | TrueType fonts have their data stored big-endian | 08:26.55 |
| hj | thanks for your time | 08:27.53 |
| chrisl | Slightly worried I might have to crank the handle on my SPARC box...... :-( | 08:27.57 |
| tor8 | sebras: the warning to exception commit looks mostly good. a few cases of variable declarations in the middle of a block though. | 10:52.17 |
| sebras | tor8: pong! | 11:01.19 |
| tor8 | sebras: ping. | 11:08.09 |
| sebras | tor8: sorry had to switch device. | 11:16.13 |
| tor8 | sebras: he warning to exception commit looks mostly good. a few cases of variable declarations in the middle of a block though. | 11:16.28 |
| sebras | tor8: I left two patches for you over at sebras/master | 11:16.38 |
| | tor8: ok, so I'll move the declarations to the top of each block. that can be done swiftly. more? :) | 11:17.18 |
| tor8 | that's all I could find in that commit. regularizing the obj < LIMIT || obj->type checks are an improvement :) | 11:18.51 |
| | inserting null values in dicts/arrays *could* be done by creating a fz_new_null 'null' object | 11:19.50 |
| sebras | tor8: yes, I wasn't sure which way to go Re: NULL values. | 11:20.49 |
| | tor8: I think there were some tests already present so I sided with those.\ | 11:21.03 |
| tor8 | sebras: I only worry about simplistic code that copies values directly without testing | 11:23.28 |
| | new_dict[foo] = old_dict[foo] will fail if old_dict[foo] doesn't exist | 11:23.47 |
| | it might be better to add 'null' objects in that instance | 11:23.58 |
| | dict[null] = 42 should still fail though | 11:24.18 |
| sebras | right, the latter seems like a no brainer. | 11:25.39 |
| | are you thinking about pdf_copy_dict()? | 11:27.42 |
| | in the former case. | 11:27.48 |
| tor8 | sebras: no. I'm thinking of javascript code that will manipulate pdf objects. | 11:28.48 |
| | pdf_copy_dict only copies entries that exist, so that should be fine | 11:29.32 |
| | but you're right in that we can currenly add NULL entries, but those should be the null object instead | 11:29.58 |
| sebras | tor8: is that perhaps a better solution? | 11:30.18 |
| tor8 | I'm not sure | 11:32.28 |
| sebras | tor8: but wait... | 11:32.58 |
| | tor8: old_dict[foo] will not fail, right? only if foo is not a name or NULL. | 11:33.17 |
| tor8 | without the null object, it's hard to distinguish the case of an absent entry (pdf_dict_get returns NULL) and one with null (pdf_dict_get returns a pdf_obj with type null) | 11:33.27 |
| sebras | tor8: if it is a valid name it will be handled in the normal way just as today, right? | 11:33.44 |
| tor8 | old_dict[foo] = NULL will fail with your second patch | 11:33.47 |
| | sorry. old_dict[foo] = new_dict[foo] will faill if new_dict[foo] is NULL | 11:34.12 |
| | I was just showing it as an example of the sort of code that might cause it to fail | 11:34.42 |
| sebras | if foo is not present in new_dict? yes I agree. | 11:34.49 |
| tor8 | so I'm thinking we should implicitly create pdf_new_null rather than throw exceptions | 11:35.22 |
| | a dictionary may only have names as keys, so throwing for a NULL key is still correct | 11:36.03 |
| | in pdf_dict_get, if (!key || (key >= PDF_OBJ_NAME__LIMIT && key < PDF_OBJ__LIMIT)) looks fishy | 11:36.20 |
| sebras | tor8: yeah, we mix true/false/null into the list of names. | 11:40.23 |
| | tor8: so previously you could do pdf_dict_put(ctx, dict, pdf_new_bool(ctx, doc, 1), pdf_new_int(ctx, doc, 42)); | 11:40.57 |
| | so in the NAMES-list we first have all recognized names, then true/false/null and finally all new names created dynamically. | 11:41.29 |
| tor8 | sebras: why not use the same formulation as in pdf_is_name? | 11:43.49 |
| | or just call pdf_is_name? :) | 11:44.59 |
| | biab, time for lunch | 11:45.03 |
| sebras | tor8: I could call pdf_is_name() but we'd do RESOLVE() unnecessarily. | 11:45.52 |
| | tor8: for me that I probably the way I'd like to go because that way we'd have the test in one place. | 11:47.18 |
| tor8 | sebras: add a PDF_IS_NAME macro that does the same but without resolve? or a static inline pdf_is_name_raw | 12:41.22 |
| sebras | tor8: what happens if we skip the resolve? shouldn't we do that before testing the type? | 12:42.17 |
| | tor8: like in pdf_dict_get(). | 12:43.00 |
| tor8 | sebras: you said you only wanted to do the resolve once... I'm suggesting an alternative to calling pdf_is_name which lets you keep your first resolve and skip the (redundant) one inside pdf_is_name | 12:43.40 |
| | sebras: it could be argued that you shouldn't try to resolve the key | 12:44.17 |
| | an indirect reference as a dictionary key is not valid | 12:44.25 |
| sebras | tor8: right. | 12:45.10 |
| | tor8: I tried to find that in the middle of the block declaraion but I cannot find it. | 13:37.20 |
| | tor8: https://github.com/sebras/mupdf/commit/920aced1514666054870571485e26ef66d005246 | 13:39.02 |
| | tor8: apparently I got lost in the diff output. found the annoying pdf_document * declaration. I'll fix when I get home. | 13:41.15 |
| | \/quit | 19:41.40 |
| | Forward 1 day (to 2016/08/24)>>> | |
IRC Logs