| | <<<Back 1 day (to 2014/01/29) | 2014/01/30 |
| chrisl | jo0nas: I can't reproduce the WOFF problem with any build from our repo (9.05/9.07/master). You'll need to open a bug on http://bugs.ghostscript.com with the minimum changes from our default build required to reproduce the problem. Also, you might mention to your user(s) that when posting error logs on bugs, running with -dQUIET is genuinely dumb | 09:54.23 |
| Robin_Watts | Morning tor8. | 13:27.43 |
| | Dunno if you saw my burblings yesterday. | 13:27.59 |
| tor8 | Robin_Watts: sorry, didn't look at your commits yet. been diving through all the popular (and impopular) regular expression implementations I could find. | 13:29.16 |
| Robin_Watts | tor8: no worries, as long as you'd seen that they were there. | 13:29.33 |
| | Did you see zenikos comments on trex? | 13:29.42 |
| tor8 | Robin_Watts: yes. I got an email from him with his fork. he's reworked it significantly. | 13:29.58 |
| Robin_Watts | He has a bugfixed version with the required js extensions. | 13:30.01 |
| | ok. | 13:30.04 |
| tor8 | the main issue I have with it is that (a) it doesn't do utf-8 and it looks like it would require a fair bit of heavy handed surgery to add that support (it does ascii and wide char string only, as a compile time thing) | 13:31.01 |
| | and (b) it uses malloc when searching (which isn't a major problem, I have to admit) | 13:31.30 |
| jo0nas | chrisl: thanks for checking! I will first upgrade to 9.10 and check if reproducible there - and if it is I shall file a bugreport about it | 14:30.51 |
| tor8 | Robin_Watts: s/impl.d/imp.h/ | 14:33.41 |
| | Robin_Watts: s/priv_/user/ | 14:33.46 |
| | or just pdf-interpret.h | 14:34.03 |
| | Robin_Watts: random question: do you want to split out the default operators in pdf-interpret.c to pdf-op-normal.c ? | 14:35.34 |
| Robin_Watts | tor8: The normal ones have gone to pdf-op-runner.c I think. | 14:36.00 |
| tor8 | libmupdf.vcproj, do we normally have .h files in the project file list? | 14:36.12 |
| Robin_Watts | The .h files have to be somewhere. | 14:36.28 |
| tor8 | Robin_Watts: ah, so you did. pdf-op-run.c in a later commit. | 14:36.35 |
| Robin_Watts | and the .h file is there rather than in the includes, because it's not part of the API. | 14:36.49 |
| tor8 | Robin_Watts: yes. | 14:36.58 |
| | s/pdf_filter_private/pdf_op_filter_state/ or something like that? private is a fairly meaningless word here I feel. | 14:37.47 |
| | op_table_state? | 14:38.04 |
| Robin_Watts | yeah. | 14:38.07 |
| | I end up with "op_runner" and "op_runner_private" | 14:38.25 |
| | but op_runner_state would be better. | 14:38.32 |
| henrys | tor8:so do you want me to talk to miles about licensing js? should I add that to the agenda or do you think it is best lift a silent component of mupdf? | 14:38.42 |
| tor8 | henrys: good question. what do you think? | 14:39.11 |
| | I sort of want the AGPL license just so people can't use it, because I *hate* javascript the language :) | 14:39.40 |
| paulgardiner | :-) | 14:39.54 |
| henrys | tor8:you would have to support it. | 14:40.04 |
| Robin_Watts | If it can usefully have a life on it's own (and it sounds like it can) then why not keep it in a separate git repo, include it as a submodule etc. | 14:40.14 |
| tor8 | but if we just want it as a silent unsupported componennt of mupdf, releasing it onto the wild with a BSD license (like zlib and jpeglib and all our other thirdparty libraries) is probably the best | 14:40.40 |
| Robin_Watts | tor8: Surely it would be better for us to AGPL it? We can always BSD it later if we want to. | 14:41.22 |
| tor8 | Robin_Watts: we'd still keep it as a submodule in mupdf, as a separate git, regardless of licensing. | 14:41.23 |
| | Robin_Watts: AGPL gives us more options. if that's what you (and henrys) think is best, I'll change the license now. | 14:41.53 |
| henrys | tor8:so I'll just leave it off the agenda. The licensing question hinges on a simple question: do you want to support it? | 14:42.03 |
| Robin_Watts | My opinion is moot here really. | 14:42.12 |
| tor8 | henrys: yes (it's my baby!), and no (it's javascript!) | 14:42.37 |
| henrys | tor8:I do agree with agpl | 14:42.38 |
| Robin_Watts | What is it called? I've seen henrys refer to it as torscript. | 14:42.49 |
| tor8 | Robin_Watts: that's another question. libjs is terribly generic. | 14:43.03 |
| Robin_Watts | muscript would be a nice name, IMHO. | 14:43.05 |
| | mu suggesting "tiny", which is ultimately the point of it, right? | 14:43.25 |
| | and it ties back nicely to mupdf. | 14:43.32 |
| tor8 | Robin_Watts: definitely the point of it! | 14:43.32 |
| henrys | Robin_Watts: I like that. | 14:43.42 |
| tor8 | it's ten times smaller (and on occasion, ten times slower) than any of the alternatives | 14:43.49 |
| | mujscript maybe? | 14:44.03 |
| | though that's more tongue twisting... | 14:44.14 |
| | moojayscript | 14:44.21 |
| Robin_Watts | Are there other scripts we might get confused for? i.e. is the j vital? | 14:44.44 |
| tor8 | Robin_Watts: there are a ton of languages with *script suffix, it might make sense to clarify that it is indeed javascript | 14:45.34 |
| Robin_Watts | I guess we might get confused with the "mupdf parser in gs" project that we call mooscript. | 14:45.43 |
| kens | tor script counds like a torretn tool | 14:45.45 |
| tor8 | mujavascript if we want to be absolutely clear (or muecmascript) | 14:45.50 |
| henrys | tor8:think about the support question, it would be fun to get something new out there and see who shows up interested in a license. | 14:45.52 |
| tor8 | henrys: I'm not opposed to supporting it, it's been a fun project so far. | 14:46.10 |
| henrys | to8:okay it goes on the agenda | 14:46.57 |
| tor8 | but we have to be clear on one thing: performance is not the point of it, a small embeddable footprint (and tight security because of the small code size and simplicity) and a easy to use API for native function binding | 14:47.28 |
| | henrys: we are still < 9000 lines of code (counting blanks) | 14:49.13 |
| henrys | tor8: that can all be stated in the agreement | 14:49.14 |
| tor8 | henrys: as long as I don't get inundated with "make it run faster" requests, I'll be happy to support it. | 14:53.46 |
| henrys | tor8:yup I think miles can craft that into any business agreement | 14:54.40 |
| | kens:yes you are straying into developing their application, we need to choose a direction for gsprint and move forward with that. If it overlaps with the customer great if not their request goes into an enhancement bug to be considered in the future. | 14:58.32 |
| kens | henrys that was my concern | 15:00.12 |
| henrys | kens:the good news is they don't seem to get very upset when we say no or wait, i.e. I think they realize the situation. | 15:01.49 |
| kens | henrys, are you OK with the mail I propose ? | 15:02.38 |
| | Obviously I'll send them the source. | 15:02.46 |
| henrys | kens:yes fine by me, I'll tell miles we've resolved it if you like or you can tell him. | 15:03.45 |
| kens | NP I will mail and BCC him | 15:06.45 |
| kens2 | Goodnight folks | 17:31.10 |
| ray_laptop | so what's wrong with mujs ? | 18:19.15 |
| | (tiny name, tiny module) | 18:19.31 |
| Robin_Watts | ray_laptop: I do like that. | 18:22.48 |
| | mvrhel_laptop: So, I spoke to some ex-picsel guys today. | 18:47.34 |
| | Apparently word is an absolute bitch to try to match layout exactly. | 18:47.53 |
| | They say the code should be pretty good horizontally, but vertically there may be more differences. | 18:48.14 |
| | Supposedly the fonts they have are clones of the postscript ones, so metrics etc shouldn't be the problem. | 18:48.43 |
| mvrhel_laptop | Robin_Watts: ok. that is what I was seeing. The vertical positions of stuff was different | 19:00.24 |
| ray_laptop | Robin_Watts: on the Windows machine that created the doc, the fonts will be on the system, right ? | 19:00.39 |
| | Robin_Watts: but I assume that the problem comes in creating the PDF (embedding the font or a subset) ??? | 19:01.09 |
| Robin_Watts | ray_laptop: But does the converter use system fonts? | 19:01.12 |
| | ray_laptop: No. | 19:01.27 |
| ray_laptop | Robin_Watts: why not ? | 19:01.27 |
| Robin_Watts | The problem as observed is that we get a slightly different layout between documents laid out in epage and documents laid out in office. | 19:02.06 |
| ray_laptop | Of course, processing a doc file that came from the wild would be a problem | 19:02.16 |
| Robin_Watts | I had speculated previously that this was because of font differences. | 19:02.25 |
| | but it now seems that it's a known problem with word files. | 19:02.37 |
| ray_laptop | Robin_Watts: even when using the same fonts ? | 19:02.53 |
| Robin_Watts | It would be interesting to see if LibreOffice/AbiWord/Microsoft Word etc all agree. | 19:02.58 |
| | As I say, I don't know that the converter accesses system fonts. | 19:03.24 |
| | But for base 35 fonts we should be OK. | 19:03.51 |
| ray_laptop | if you don't use the same font, getting the layout right is impossible (unless you are extremely lucky with the metrics of the font you use to substitute) | 19:04.22 |
| Robin_Watts | ray_laptop: Right, and I don't think anyone of us would care if we got different results with documents that use non-standard fonts. | 19:04.57 |
| ray_laptop | The base 35 PS fonts have different metrics to those same 35 fonts in TTF form (which is what Word uses) | 19:05.16 |
| | AFAIK, Word can't work with PS fonts. Just TTF and OpenType | 19:05.58 |
| mvrhel_laptop | Robin_Watts: I am going to poke around now at lcms | 19:39.05 |
| | is this still the patch? | 19:39.15 |
| | http://git.ghostscript.com/?p=user/robin/ghostpdl.git;a=commitdiff;h=cdae1c9f93bda0b8c45ecc3d59df066fbff74aed | 19:39.16 |
| Robin_Watts | yes. | 19:39.39 |
| | oh., urm... | 19:40.15 |
| | No. | 19:40.34 |
| | This is the patch: http://git.ghostscript.com/?p=user/robin/ghostpdl.git;a=commitdiff;h=24672833660644f1e6ffb78c2ffd90ffb2d65674 | 19:40.37 |
| mvrhel_laptop | ok | 19:40.57 |
| Robin_Watts | It's the lcms2_thread branch on my repo. | 19:41.00 |
| mackross | Sorry ray_laptop I had to run out of the office last night but I was able to get the build to compile this morning :) unfortunately it has introduced a new font colour bug. Trying to reproduce on my mac now | 20:24.15 |
| Robin_Watts | mvrhel_laptop: If you want me to have a go at reducing the example file for the "image fades to white bug" just say. | 20:26.03 |
| mackross | awesome totally reproducable! | 20:36.47 |
| mvrhel_laptop | Robin_Watts: what bug is this? | 20:55.21 |
| Robin_Watts | 694874 | 20:55.50 |
| mvrhel_laptop | oh. Robin_Watts yes if you can reduce this that would be great | 20:56.36 |
| Robin_Watts | I will give that a whirl tomorrow. | 21:00.55 |
| ray_laptop | can someone please give me a review on a really simple patch. I discovered that on linux, the "real" max memory (commit da944b290302bf9391116b806c4a368b7d185d94) didn't show up because it didn't use the 'iapi' methods. | 21:11.04 |
| | the patch is on my personal repo: http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=429640b32e1ffcd324c2b44daa1fb35ef41c01d4 | 21:11.25 |
| | I moved it to the gs_malloc_release so it works for all systems now | 21:11.56 |
| | compared to my last commit (for the pdf14 clist accumulator) this one is easy. :-) | 21:12.50 |
| mackross | ray_laptop thanks for the help yesterday sorry I had to leave the office in a rush. | 22:01.41 |
| Robin_Watts | ray_laptop: (For the logs) Looks good to me. | 23:39.34 |
| | ray_laptop: (For the logs) Looks good to me. | 23:48.06 |
| | Forward 1 day (to 2014/01/31)>>> | |
IRC Logs