| | <<<Back 1 day (to 2015/08/23) | 20150824 |
| Robin_Watts | tor8: Morning. | 09:23.03 |
| | Did you have pending reviews? | 09:23.09 |
| tor8 | Robin_Watts: morning. | 09:24.14 |
| | yes, there's a handful on tor/master, including a better utf-8 on windows fix | 09:24.32 |
| Robin_Watts | tor8: Will look now. | 09:24.46 |
| | There is one on robin/master | 09:24.52 |
| tor8 | the utf-8 fix is a bit awkward on mingw, the _MSC_VER vs _WIN32 ifdeffing has a few issues there | 09:25.14 |
| | Robin_Watts: the two android functions LGTM | 09:26.32 |
| | I've also managed to make the opengl-based viewer build on windows with MSVC | 09:27.02 |
| Robin_Watts | tor8: Thanks. I've just pushed a fixed version of the the gprf_metadata one to robin/master | 09:28.56 |
| | tor8: Ah, nice. | 09:29.05 |
| tor8 | I've got a few oddities with the project setup with MSVC that I need your help with | 09:29.35 |
| | probably easiest if you actually try the tor/glut branch out | 09:29.54 |
| | you need to clone glfw into thirdparty. I set up a git mirror repository on casper. | 09:30.22 |
| Robin_Watts | Hmm. Did git not spot that ucdn.h was moved ? | 09:30.36 |
| | Maybe the git web diff stuff just doesn't show it as I'd expect. | 09:31.11 |
| tor8 | git web diff doesn't detect moves | 09:31.55 |
| | I use gitk | 09:32.00 |
| | Robin_Watts: gprf metadata also looks reasonable | 09:34.42 |
| Robin_Watts | OK, I've pushed all your master commits except the last one. Will look at that now. Ta. | 09:34.54 |
| tor8 | though personally I'd just use fz_strlcpy rather than snprintf | 09:35.06 |
| Robin_Watts | tor8: That's a line cut and pasted from pdf. | 09:35.58 |
| | ah, but the pdf one had versions in. | 09:36.13 |
| | yeah. | 09:36.16 |
| | ah well, next time :) | 09:36.22 |
| | I am confused by the utf-8 stuff. | 09:38.16 |
| | We convert wargv (wchars) to argv (chars) | 09:39.01 |
| | s/chars/utf8/ | 09:39.16 |
| | So filename is set to a utf-8 thing. | 09:39.39 |
| | Why do we then pass filename to WideCharToMultiByte ? | 09:39.56 |
| | Oh, that's just in the winfilename case. Sorry, diff was confusing me. | 09:40.44 |
| tor8 | that filename is from the popup file dialog | 09:41.02 |
| | yeah, diff looks confusing | 09:41.09 |
| Robin_Watts | Yeah, that looks great then. Ta. | 09:41.26 |
| | All pushed | 09:41.35 |
| tor8 | Robin_Watts: great, thanks. | 09:41.54 |
| | Robin_Watts: okay, updated tor/glut branch with the submodule repository added in | 09:58.47 |
| Robin_Watts | tor8: Fab. Will look at that now. | 09:59.03 |
| | tor8: Can we use GetWindowLongPtr instead of GetWindowLongPtrW ? | 10:08.40 |
| tor8 | any particular reason? I expect to add a few patches to GLFW anyway, so doing so wouldn't be an actual problem. | 10:10.44 |
| Robin_Watts | D'Oh. | 10:11.30 |
| tor8 | I personally prefer code that uses the A or W suffixes explicitly | 10:11.33 |
| Robin_Watts | I thought this was our calling code. | 10:11.37 |
| | There are warnings from it, but if it's thirdparty code that's fine. | 10:11.54 |
| tor8 | but I don't mess with win32 often enough to have a firm opinion | 10:11.57 |
| Robin_Watts | ok, it all seems to build nicely enough on my machine. | 10:15.17 |
| | and run. | 10:15.27 |
| | Let me look at the actual commits now. | 10:15.36 |
| tor8 | it doesn't pop up a window asking for a file, but if you drag-and-drop it should open up a window | 10:15.46 |
| Robin_Watts | Urm... what? | 10:16.44 |
| tor8 | mupdf-gl.exe takes a file name argument | 10:16.53 |
| | it doesn't open up a file dialog like our old viewer (haven't got around to that part yet) | 10:17.08 |
| Robin_Watts | Ok. So you'll be wanting to ignore everything I've just said. | 10:17.20 |
| tor8 | you ran the old viewer :) | 10:17.31 |
| Robin_Watts | Cos I was expecting mupdf.exe to be the gl one now :) | 10:17.33 |
| | yeah | 10:17.35 |
| | It's a monday. | 10:17.39 |
| tor8 | No worries. | 10:17.44 |
| | if you get it running, the 'o', 'l', and '/' keyboard shortcuts show off the main improvements over the old one | 10:18.42 |
| Robin_Watts | I can't flip pages with arrow keys any more? | 10:18.50 |
| tor8 | 'o' opens an outline side bar | 10:18.52 |
| | arrow keys only pan within the page | 10:19.05 |
| | space and 'b' behave like the android viewer when zoomed in | 10:19.16 |
| Robin_Watts | What is 'l' supposed to do? | 10:19.39 |
| | oh, I see. | 10:19.48 |
| tor8 | toggle link highlighting | 10:19.49 |
| | there are probably a few glitches left in the swap from GLUT to GLFW | 10:20.00 |
| Robin_Watts | Pointer could change to a finger when over a link? | 10:20.07 |
| tor8 | the event handling is a bit different, and I haven't ironed out all the kinks yet | 10:20.12 |
| | yeah, I think we could do that now. | 10:20.29 |
| | though we do a mouse-over highlight already | 10:20.42 |
| Robin_Watts | 12g takes me to page 1. | 10:21.08 |
| tor8 | yeah, there's a fix for that if you just update the branch | 10:21.18 |
| | the search text editing supports actual cursor navigation and mouse selection, etc | 10:22.27 |
| | and during searching, you get progress messages and can press ESC to cancel | 10:22.43 |
| Robin_Watts | I get warnings from gs-main.c | 10:23.06 |
| | I get warnings from gl-main.c | 10:23.10 |
| | 3>c:\artifex\mupdf.git\platform\gl\gl-main.c(196) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data | 10:23.21 |
| | 3>c:\artifex\mupdf.git\platform\gl\gl-main.c(491) : warning C4305: 'function' : truncation from 'double' to 'GLfloat' | 10:23.23 |
| | lots of the latter. | 10:23.29 |
| | Could we call glColor4d instead? | 10:23.42 |
| tor8 | yeah, implicit conversion of double literals to floats :( | 10:23.52 |
| | I'll add 'f' suffixes to the literals | 10:24.48 |
| | Robin_Watts: do you know what has caused the 'LIBCMT' linker warning? | 10:42.34 |
| Robin_Watts | It's the choice of Runtime Lib, probably. Let me poke. | 10:43.54 |
| | libglfw is set to use Multi-Threaded Debug DLL. | 10:48.40 |
| tor8 | where is that set and what do I change it to? | 10:51.57 |
| Robin_Watts | Right hand click on libglfw, choose properties. In that window, C/C++ -> Code Generation | 10:52.47 |
| | Runtime Library... you want Multi-threaded Debug, not Multi Threaded Debug DLL | 10:53.07 |
| | and for release Multi-Threaded, not Multi-Threaded DLL | 10:53.24 |
| | The pdb stuff is giving lots of warnings though. | 10:54.03 |
| | I think more than one lib is trying to build to the same .pdb at once. | 10:54.15 |
| tor8 | and likewise with the debug codegen for the mupdf-gl project | 10:54.50 |
| | I'm not seeing any pdb warnings | 10:55.19 |
| Robin_Watts | Do a rebuild of the whole solution? | 11:04.02 |
| | It's not a big deal. | 11:04.12 |
| tor8 | nope, nothing. could be a personal setting to use pdb files or parallel builds? | 11:05.56 |
| Robin_Watts | yeah, don't sweat it. | 11:18.48 |
| | tor8: The commit message for "glut: Links with mouseover highlighting." could have the "Conflicts:" lines removed. | 11:37.24 |
| | tor8: This is not a criticism, because I'm sure I do it elsewhere too, but code like: | 11:41.49 |
| | +if (scroll_y < 0) | 11:42.00 |
| | +scroll_y = 0; | 11:42.02 |
| | +if (scroll_y + canvas_h > page_h) | 11:42.04 |
| | +scroll_y = page_h - canvas_h; | 11:42.05 |
| | is crying out for an scroll_y = fz_clamp(scroll_y, 0, page_h - canvas_h) | 11:42.42 |
| | The standard viewer, on windows/linux has a document properties window. And an 'about' window that gives key presses. | 11:44.35 |
| tor8 | Robin_Watts: yeah. | 11:46.45 |
| Robin_Watts | "glut: Use middle button to scroll outline view." has "Conflict" lines too. | 11:47.41 |
| tor8 | Robin_Watts: remnants of rebasing, I think | 11:47.59 |
| Robin_Watts | Do those variables in draw_outline all need to be static ? | 11:48.14 |
| tor8 | can easily be cleaned up. or just squished. | 11:48.14 |
| | Robin_Watts: it's that or global. they need to be preserved across frames. | 11:48.57 |
| | though, ahem, scroll_y is shadowing a global already | 11:49.42 |
| Robin_Watts | tor8: I wasn't sure that both scroll_y and save_scroll_y needed to be global, but that may be because I can't quite make out the purpose of save_scroll_y | 11:54.07 |
| tor8 | there are two sets of scroll_y and save_scroll_y. one for the outline view, and one for the canvas view. | 11:54.28 |
| | save_scroll_y is the value of scroll_y at the beginning of a mouse drag operation | 11:54.48 |
| | so we can compute the correct delta values ( | 11:55.07 |
| Robin_Watts | scroll_y_drag_origin ? | 11:55.48 |
| | As a general style point, perhaps it would be nicer to have a single 'globals' structure and hold all the globals in that? | 11:56.51 |
| tor8 | or old_scroll_y | 11:57.06 |
| Robin_Watts | That way at least it'd be clear what are globals, and what aren't. | 11:57.09 |
| | "old" implies "the last time this code was called" | 11:57.45 |
| tor8 | which is pretty much what I mean | 11:57.58 |
| Robin_Watts | "drag", "start", or "initial" would imply the position at the start of the drag operation. | 11:58.18 |
| tor8 | but not strictly, which is why I called it saved rather than old | 11:58.33 |
| Robin_Watts | So saved_scroll_y is updated on every call? | 11:58.44 |
| | rather than just at the start ? | 11:59.01 |
| tor8 | it's saved just at the start | 11:59.28 |
| Robin_Watts | Then it's not 'old', IMHO, it's 'inital' or 'start'. | 11:59.51 |
| tor8 | so start or initial is probably a better name if 'save' is unclear | 12:00.02 |
| Robin_Watts | (or 'saved' :) ) | 12:00.03 |
| tor8 | yeah, I don't know why I didn't write saved... | 12:00.30 |
| | I blame english as a second language ;) | 12:00.43 |
| Robin_Watts | When I see 'saved' I think of 'save this temporarily so it can be restored later'. | 12:01.00 |
| | Whereas 'initial' or 'start' carries the implication of when the value was set. | 12:01.45 |
| | In "glut: Add text for search" is there a reason why you #if 0 measurestring rather than just remove it? | 12:02.48 |
| tor8 | I expect to use it eventually | 12:03.05 |
| | to layout text labels and buttons when I add the 'about this document' dialog | 12:03.34 |
| | but I hated seeing the warning | 12:03.47 |
| Robin_Watts | fz_utf8_from_rune_string... checking the return value from fz_malloc seems odd. Do you mean fz_malloc_no_throw or whatever it is? | 12:03.50 |
| | tor8: Fair enough. | 12:04.03 |
| | #ifdef FOR_FUTURE_USE :) | 12:04.24 |
| tor8 | ah, that's a bit of code I ported from an #ifdef _MSC_VER time.c which used plain malloc | 12:04.46 |
| Robin_Watts | There is a printf("searching page %d\n", i); etc in there too. | 12:05.09 |
| | Either that's debug code, and should go, or it's useful code, and we should do something that would make it work under windows. | 12:05.36 |
| | There is a degree of 'magic number'ness to this code. | 12:06.56 |
| | ui_input_draw(canvas_x, 0, canvas_x + canvas_w, 15+4, &search_input); | 12:07.07 |
| | Why 15+4 ? | 12:07.10 |
| tor8 | debug code. it's removed in newer code where we also periodically pause searching to display a 'searching page %d / %d' message on the window | 12:07.11 |
| Robin_Watts | ok. | 12:07.24 |
| tor8 | 15 is the line height, also moved to a variable in a later commit, and 4 is the amount of extra white space | 12:07.42 |
| Robin_Watts | Picsel used to have a 'no magic number' requirement. We were encouraged to use things line LINE_HEIGHT + WHITESPACE and have those as enums etc. | 12:08.11 |
| tor8 | yeah, I'm expecting to clean up the hardcoded layout numbers some more | 12:08.26 |
| | the Use GLFW instead of GLUT commit adds the layout variables while to adding proper opengl text rendering using our built-in times/droid sans fallback fonts | 12:09.45 |
| | so we can easily tweak the font size if need be | 12:09.58 |
| | I'm going to add a 'pixelscale' scaling value for all other numbers as well, to deal with retina displays | 12:10.17 |
| | there are a lot of globals; I expect I can refactor several of the functions and make the variables statically scoped | 12:11.08 |
| Robin_Watts | The GL font rendering stuff is not used for any of the document stuff, right? It's for the UI ? | 12:11.17 |
| tor8 | just for the UI | 12:11.24 |
| Robin_Watts | tor8: Yeah. | 12:11.41 |
| | I can see that it makes sense to use globals for this stuff. | 12:11.50 |
| | I'm just trying to sort out in my head how I feel about it. | 12:11.59 |
| tor8 | one of the next steps I'm going to do is move all the keyboard event handling into the 'on_display' function | 12:12.20 |
| | then the need for many of the globals will go away | 12:12.27 |
| Robin_Watts | I think I like the idea of having structures 'per compilation unit' where possible, and putting the globals into that as appropriate. | 12:12.40 |
| tor8 | the on_keyboard should just stuff the keypress into an event queue which the on_display function will read out of | 12:12.45 |
| Robin_Watts | Mememto uses a 'globals' structure, that I should probably have called Memento_Globals. | 12:13.00 |
| | it means that usages become Memento_Globals.sequence++; rather than sequence++; which is clearer, IMHO. And it's less polluting to the namespace. | 12:13.43 |
| tor8 | the gl-font.c code uses a 'g_' prefix for its globals | 12:13.44 |
| | old code I salvaged from another project | 12:13.50 |
| | I never let globals be visible outside the compilation unit | 12:14.13 |
| | if I can avoid it | 12:14.19 |
| | but a globals structure named after the module makes a lot of sense for code clarity (though not brevity) | 12:14.40 |
| Robin_Watts | yeah. But it's easy to shadow things unwittingly. | 12:14.50 |
| tor8 | yeah, compilers are bad about shadowing warning :( | 12:15.06 |
| Robin_Watts | OK, all those commits look fine to me, with the minor points I've listed above. No showstoppers. | 12:15.32 |
| | I can't see where the printf's are removed though. | 12:15.58 |
| tor8 | fixed some of them already, going to keep banging away on the code structure so the globals and hardcoded layout numbers | 12:17.47 |
| | hm, I can find only one printf remaining, which should be nuked | 12:17.59 |
| Robin_Watts | copy clipboard? | 12:18.08 |
| | on_search has one. | 12:18.31 |
| tor8 | copy clipboard has been removed. on_search I just nuked. | 12:19.36 |
| chrisl | Huh, so the PCL and XPS interpreters don't support COMPILE_INITS=0 at all..... <sigh> | 13:46.36 |
| kens | Hmmm, is that becase they don't really need resrouces, except fonts ? | 13:47.13 |
| tor8 | chrisl: the only thing I can think of in XPS would be mvrhel's colorspace ICC profile stuff? | 13:47.16 |
| chrisl | XPS yes, only needs ICC profiles, PCL needs both profiles and fonts | 13:47.38 |
| | Still feel it's decidedly shit | 13:48.39 |
| henrys | chrisl: so that's a regression with the new layout right? | 13:49.14 |
| chrisl | henrys: nope, not at all | 13:49.31 |
| henrys | I wonder when it broke because I'm quite sure I'd built it in the past | 13:50.03 |
| chrisl | It's a long standing problem that now shows up because the makefiles now honor the setting | 13:50.12 |
| | henrys: comment in the old pcl6_gcc.mak file: "This is constant in PCL, XPS and SVG, do not change it. A ROM file system is always needed for the icc profiles." | 13:51.11 |
| henrys | oh right I wasn't really worried about that, I thought the fonts could be split out and we should support that. | 13:52.18 |
| | though I guess making uber exes is not much an issue anymore | 13:52.45 |
| chrisl | Well, no, you either have a romfs or you don't - there's no halfway house | 13:52.46 |
| henrys | chrisl: I distincly remember setting up a halfway house... hold on. | 13:53.38 |
| | chrisl: there is an environment variable called PCLFONTSOURCE if set to a path it should use that. It does need some documentation. You just delete the fonts before building and set that variable to the path of the fonts. | 13:57.39 |
| | chrisl: is there some reason that shouldn't work with what you've done recently? | 13:58.36 |
| chrisl | henrys: mainly because the makefiles now honor the COMPILE_INITS value - as they are supposed to. | 13:59.06 |
| Robin_Watts | If you set COMPILE_INITS to 0, then you get no ROMFS at all, and hence pcl doesn't have any ICCProfiles to work with? | 13:59.43 |
| chrisl | Ghostcript works with "./configure --disable-compile-inits" - PCL and XPS should work as well | 14:00.10 |
| kens | Same as GS, you need to supply it with a directory spec. | 14:00.13 |
| henrys | chrisl: I see yes that is broken then. | 14:00.16 |
| chrisl | AFAIK, PCL/XPS doesn't support -I or an equivalent | 14:00.49 |
| Robin_Watts | So COMPILE_INITS is really HAS_ROMFS ? | 14:00.53 |
| kens | chrisl, I guess its not going to work then. | 14:01.03 |
| chrisl | Robin_Watts: actually we always have a romfs, it's just with COMPILE_INITS=0 it is empty | 14:01.26 |
| tor8 | Robin_Watts: rats. mutool clean -s in sanitize() seems to have a double free error :( | 14:02.42 |
| Robin_Watts | So... for the pcl builds, COMPILE_INITS should maybe just determine whether the fonts are included in romfs or not? | 14:02.46 |
| chrisl | I'll tweak the builds so gpcl6, gxps and gpdl ignore COMPILE_INITS for now | 14:03.00 |
| | Robin_Watts: that's inconsistent | 14:03.16 |
| henrys | chrisl: that would be my preference | 14:03.21 |
| Robin_Watts | The name "COMPILE_INITS" would suggest to me that it controlled whether the initialisation files were compiled in or not. | 14:04.19 |
| | pcl doesn't have 'initialisation files', right? | 14:04.32 |
| henrys | yeah COMPILE_INITS is poorly named | 14:04.57 |
| Robin_Watts | ROMFS_{INITS,FONTS,PROFILES} as separate options maybe? | 14:05.11 |
| henrys | fonts and icc profiles are not INITS to me. | 14:05.16 |
| chrisl | But COMPILE_RESOURCES is a bit long.... | 14:05.39 |
| | And, FWIW, as the ICC profiles are required during initialisation and influence the runtime behaviour they are, at least arguably, initialisation files | 14:07.58 |
| henrys | chrisl: it wouldn't be hard to fix, I guess I don't feel strongly about it, yes nice to be consistent, but of little utility to XPS and PCL so why yet another configuration to test? | 14:12.38 |
| chrisl | henrys: I'm having to *add* exceptions to the build to work around this - so this is adding to the complexity of the build | 14:13.52 |
| henrys | chrisl: okay so we'll make an enhancement should we do it right now or do you want to put in a stopgap and return to it? | 14:15.33 |
| | I can add another variable like PCLFONTSOURCE for the profiles. | 14:16.00 |
| kens | I feel consistency is more than just 'nce', its a constant surprise when things are inconsistent, and leads ot having to revise code when its discovered that various things don't work as expected. | 14:16.02 |
| chrisl | henrys: as it's not a regression, I don't think it's urgent. | 14:16.34 |
| henrys | I'll make an enhancement to me in bugzilla | 14:18.34 |
| chrisl | henrys: does pcl accept the command line options for setting the ICC profile search directory? | 14:19.22 |
| henrys | it parses it, not sure if I look at it, hang on. | 14:20.24 |
| | chrisl: yup should work | 14:21.10 |
| chrisl | henrys: okay, so all we really need is some extra error checking, and it will work as I would expect | 14:21.32 |
| henrys | chrisl: if I say hang on that means it wasn't tested well enough for me to remember, a bad sign ;-( | 14:21.51 |
| | chrisl: the code looks plausible | 14:23.21 |
| chrisl | henrys: I'll have a play with it, and see | 14:23.43 |
| henrys | chrisl: I did get it to compile ;-) | 14:24.00 |
| Robin_Watts | kens: The principle of least surprise. Indeed. | 14:24.50 |
| kens | I htink GS operates on the principle of maximum surprise, presumably someone was reading Pterry's work | 14:25.40 |
| | For those not up to dayte on Discworld, there are 5 elements, Earth, Fire, Air, Water, and the fifth element (groan) surprise | 14:26.30 |
| henrys | I do like COMPILE_RESOURCES for fonts,profile, etc., and COMPILE_INITS for Resources/Init | 14:27.06 |
| | but no big deal | 14:27.16 |
| chrisl | But "Resources/Init" contains Postcript resources, too :-( | 14:27.42 |
| Robin_Watts | henrys: If we were to split inits/resources, I'd be tempted to split init/fonts/profiles | 14:27.55 |
| kens | Ints are in the PostScript resources folder | 14:28.36 |
| | Inits* | 14:28.43 |
| | Fonts really ought to be there too :-) | 14:29.05 |
| chrisl | And break out the PDF interpreter files, too?? | 14:29.26 |
| Robin_Watts | fonts/profiles/others :) | 14:30.08 |
| | I can imagine people maybe wanting to put gs into a device where they share the fonts with other components. | 14:30.48 |
| | similarly the ICCProfiles. | 14:30.56 |
| | Not so much the pdf interpreter or other ps resources :) | 14:31.16 |
| chrisl | People doing that will be tweaking makefiles, anyway | 14:31.18 |
| Robin_Watts | Think how overjoyed they would be to have to only tweak the makefiles a tiny bit rather than lots. | 14:31.53 |
| henrys | a good small step would be to split out the fonts entirely, surely they have nothing to do with initialization and there is a case for wanting to have a romfs with fonts on the file system. | 14:31.54 |
| chrisl | henrys: the PCL interpreter reads all the fonts during initialisation...... | 14:32.21 |
| kens | For PostScript, Fonts are a resource, and (I htnk) wee find our init files as a resource too. | 14:33.42 |
| | Although its true we can add extra font searches, so we could have an empty Fonts* resource in ROMFS I guess | 14:34.10 |
| chrisl | kens: as I said, the "Init" directory also contains definitions of resources, so...... | 14:34.20 |
| kens | Indeed. | 14:34.42 |
| | Ah drat, I forgot to pick up chrisl's font commit, no wonder I have loads fo diffs :-( | 14:36.21 |
| henrys | chrisl: well yes it requires fonts (actually not in HPGL2-RTL mode) but I don't think of that as initialization. | 14:37.29 |
| chrisl | henrys: Okay, so the "-sICCProfilesDir=" option does *not* work with PCL because we allocate graphics state and initialise the ICC world *before* we parse the command line options | 14:41.20 |
| kens | Ah, the opposite of my pdfmark problems :-) | 14:41.50 |
| chrisl | Well, it's because we install the nulldevice when we create the initial graphics state in the graphics library - and the device requires ICC profiles | 14:42.47 |
| henrys | the way I read the code it should override it. | 14:43.59 |
| chrisl | What should override what? | 14:44.16 |
| henrys | gs_setdefaultrgbicc() for example. | 14:45.04 |
| chrisl | But this is happening before we parse the command line | 14:45.33 |
| henrys | you made a directory and put a profile in it and passed the name of the profile to the interpreter? | 14:45.34 |
| | let me look because Michael and I did test this I shakily recall... | 14:46.15 |
| chrisl | henrys: we create the initial graphics state(s) in pl_main_universe_init() which happens several lines *before* we call pl_main_process_options() | 14:46.46 |
| henrys | right then after that we read the option get the new profile and override what's in the graphics state, no? | 14:47.31 |
| chrisl | We don't get that far. We can't open any icc profiles during pl_main_universe_init() so it fails and we exit *before* we start parsing command line options | 14:48.56 |
| henrys | chrisl: I think the confusion is that it does need the romfs profiles. | 14:49.48 |
| chrisl | henrys: Ghostscript doesn't | 14:49.59 |
| henrys | but they can be overriden | 14:50.02 |
| | right | 14:50.22 |
| chrisl | There are just *so* many ways in which the PCL interpreter fails to drive the graphics library in the expected fashion :-( | 14:52.28 |
| henrys | the graphics library doesn't have an expected fashion | 14:53.06 |
| chrisl | Generally, the way Ghostscript does it is the "expected fashion" | 14:53.57 |
| henrys | well we can try to reorder things but I think we'll trip over a lot of stuff because the graphics library api is weak and vast. | 14:58.51 |
| | of course we'd have to change XPS too. | 14:59.31 |
| chrisl | For now, I think I should tweak the build so PCL and XPS ignore COMPILE_INITS - this is rapidly snowballing :-( | 14:59.50 |
| henrys | yea I'm afraid we are only going to put it off until language switch though, you are right that it is terribly inconsistant and probably one of the reason why the last language switch failed so miserably | 15:02.28 |
| chrisl | I'm just wondering how many more of these types of inconsistency are lurking..... | 15:03.05 |
| henrys | I know it was very unpopular last I brought it up but splitting out the PXL, XPS, and PCL parser and making them plugins to the PS/PDF ghostscript parser and just getting rid of all of this front end crap seems very appealing to me and I'm not convinced it would be less work. | 15:05.52 |
| chrisl | henrys: the only problem with that is the Postscript "baggage" would add a lot to the size of a basic PCL or XPS executable | 15:07.06 |
| henrys | chrisl: I wonder if we could cleverly compile away some stuff though. | 15:08.01 |
| Robin_Watts | henrys: I'm not sure why you see it as being an advantage to plug them into the gs language, rather than having them all as plugins to the gs graphics lib | 15:08.22 |
| henrys | Robin_Watts: that's what we did before and as chrisl noted pcl has gone off in it's own direction and now we have very different front ends | 15:09.24 |
| Robin_Watts | henrys: No. | 15:09.36 |
| | That's not what you did. | 15:09.42 |
| chrisl | henrys: an interpreter plugin implies a dependency on the interpreter - which brings all of PS with it.... | 15:09.58 |
| Robin_Watts | What you did before was to write a bunch of interpreters that all used (and abused) the gs lib. | 15:10.07 |
| | each one having a different frontend. | 15:10.29 |
| | I'm suggesting having a single frontend/graphics lib, and then having the interpreters plug into that. | 15:10.43 |
| henrys | Robin_Watts: I think a well defined API would work fine, but I don't believe it will happen. Ghostscript is too "attached" to the GL | 15:12.52 |
| Robin_Watts | henrys: I don't think it's that bad. I got part way down that path before I got dragged off to other things. | 15:14.04 |
| chrisl | henrys: Robin_Watts is only taking about a "front end", not an entire GL API | 15:14.45 |
| Robin_Watts | The GL already has an API (however much it's abused, it is an API). | 15:15.12 |
| | For mvrhel: http://www.fastcoexist.com/3039371/visualizing/this-is-what-your-city-would-look-like-if-all-the-worlds-ice-sheets-melt#4 | 15:17.08 |
| henrys | well obviously the API does not constrain the order of initialization and it has many other problem. I don't know at what point you stop calling something an interface... but GL is pretty close | 15:19.16 |
| Robin_Watts | henrys: The problem is that callers (in particular PCL) assume stuff they shouldn't about what they are allowed to do. | 15:20.28 |
| | For instance, AIUI, PCL calls the graphics lib with indexed colorspaces, and then continues to modify those colorspaces. | 15:21.02 |
| chrisl | And calls gs_definefont() and continues to modify the font's contents...... | 15:21.38 |
| henrys | I could look at those but a good api wouldn't allow that right. The structures would be opaque. PCL generally doesn't poke at the graphics library because it is an opaque structure. | 15:25.31 |
| | s/graphics libray/graphics state/ | 15:25.50 |
| Robin_Watts | A good API that allowed that would be very clearly documented about exactly what could be modified after the fact and what could do. | 15:26.27 |
| | A good caller of an API would not assume that such things were possible without being documented. | 15:27.08 |
| chrisl | Ideally, that's true. But there are plenty of well defined APIs out there that don't (fully) hide their details - that's not really an excuse for abusing them | 15:27.10 |
| henrys | chrisl: I know about the color index stuff, but am not so sure I understand chrisl's issue with definefont? what's that about? | 15:27.55 |
| Robin_Watts | There are inevitably structures shared by both sides of any (non trivial) API. It's down to a question of ownership really. | 15:28.01 |
| chrisl | henrys: during glyph rendering, the PCL interpreter (potentially) changes the wmode setting in the font | 15:28.41 |
| henrys | oh plchar.c:612? I don't remember what caused that. | 15:32.59 |
| chrisl | I'm not sure, but it caused me many headaches with the FAPI code..... | 15:33.26 |
| henrys | but it date to 2006 so it's probably not necessary | 15:33.36 |
| | s/date/dates | 15:33.41 |
| | chrisl: actually I was hoping to see much of plchar.c and plfont.c, if we don't add the pcl font types to the graphics library how is this ever to be sane? | 15:51.10 |
| | chrisl: actually I was hoping to see much of plchar.c and plfont.c disappear, if we don't add the pcl font types to the graphics library how is this ever to be sane? | 15:51.31 |
| chrisl | henrys: in terms of font types, there is only intellifont that is specific to PCL | 15:52.59 |
| henrys | and all the downloaded fonts | 15:53.52 |
| | bitmap fonts ... | 15:54.23 |
| chrisl | Those are either bitmap or TTF - not PCL specific | 15:54.24 |
| kens | Those are just the equivalent of PostScript type 3 though ? | 15:54.33 |
| henrys | so why is all this processing code in plchar.c and plfont.c? | 15:54.56 |
| kens | Well somethign has to render it, same as a type 3 glyph | 15:55.34 |
| | You run PostScript to get a bitmap for tha one | 15:55.42 |
| kens | admits to knowing very little about pclchar.c and pclfont.c | 15:56.22 |
| chrisl | henrys: well, we'll always need the interpreters to handle making their own special font information into something the graphics library can understand | 15:57.27 |
| | There is probably stuff that can be dropped from plchar.c,. though | 15:59.14 |
| henrys | chrisl: I'm not sure if it's clear from the code but pcl converts fonts to plfont_t (plfont.h) there shouldn't be a language dependency after that. So I'm thinking it would be better to move that into graphics library with the fonts just allow pcl to fool with them through your API. | 16:00.48 |
| | I think that would clean things up mightily but again a lot of work. | 16:01.20 |
| chrisl | henrys: but the plfont structure contains a lot of PCL specific stuff - irrelevant to the graphics library | 16:01.59 |
| | henrys: the way it should work is that PCL should convert fonts to gs_font and work with those | 16:03.15 |
| henrys | chrisl: yes I was thinking we'd have a cleaner design if we had a general purpose font library that supported PCL font or any other type of PDL font. | 16:08.26 |
| chrisl | henrys: we do: gs_font | 16:08.56 |
| henrys | the stuff in plfont_t belongs in gs_font, that's what I mean. just like type 1 is a type of font, so would downloaded tt bitmap fonts be a type | 16:11.13 |
| chrisl | Yes, so gs_font is the "container type", and then we have sub-types as we do for Type 1, CFF etc | 16:12.20 |
| | Sure, we could do that | 16:12.43 |
| henrys | that was my thought, I believe the current layout results in abuse. | 16:12.46 |
| chrisl | The only thing we really have to add is intellifont - everything else is supported, or trivially added | 16:13.46 |
| kens | We already have font types for the PCL fonts, I thnk. | 16:14.09 |
| | THe FontType member of the gs_font structure I mean | 16:14.19 |
| chrisl | Yes, but we don't really handle intellifont and bitmap font in the graphics library. IIRC | 16:14.47 |
| kens | Bug691289.pdfI'm sure you are correct | 16:14.58 |
| | But I think the downloaded bitmap fonts could easily be regarded the same as a PS Type 3 font | 16:15.29 |
| | (pdfwrite does this already) and I *think* that the stick font can be similarly handled. | 16:15.45 |
| chrisl | Kind of, yes | 16:15.54 |
| kens | It does make sense to move the PCL font types into the graphcs library | 16:16.17 |
| | As far as we can, anyway, I'm not too sure about Intellifont | 16:16.30 |
| chrisl | Intellifont is just another outline format - IIRC, it doesn't contain anything PCL specific (not like PDF/PS Type 3 fonts) | 16:17.20 |
| kens | Oh well, it should be possible to deal with it then. | 16:17.32 |
| chrisl | Yeh, I think so | 16:17.41 |
| kens | ANyway, my head hurts from dealign with graphics states all day, I'm off. GOodnight all | 16:17.55 |
| chrisl | Actually, I think I ignored it before because henrys reckoned it was extremely rare, and not worth worrying about these days..... | 16:18.20 |
| henrys | having an early lunch today bbiaw | 16:47.38 |
| fredross-perry | one more ghostscript.com/~fred/gsproof-dev.apk. | 18:26.36 |
| Robin_Watts | fredross-perry: Morning. Did my wibblings on email this morning make sense? | 18:28.39 |
| | fredross-perry: For the logs: What *should* go in the intent, is the desired starting page. | 18:33.06 |
| | fredross-perry: I don't get the separation selection menus in this version. Perhaps mIsProofing is not working? | 18:34.56 |
| sebras | tor8 (for the logs): nope, chinese input doesn't work. while it registers the right key-values to ui_input_keyboard() they appear to fall outside of key == ' ' || (cat > LL && cat < ZL), so they are never added to search_input.text and hence not to search needle. | 19:16.02 |
| fredross-perry | yes, thanks. See my responses. I checked a couple of things into my repo as a result. | 19:26.14 |
| | Robin_Watts: yes, thanks. See my responses. I checked a couple of things into my repo as a result. | 19:37.42 |
| henrys | busy day on wall street | 20:09.22 |
| sebras | tor8 (more for the logs): after lots of pointless searching I eventually found that the general category for at least U+4F60 is wrong in the database of the ucdn version we embed. it is not supposed to be CN as it is today, but rather LO. this was fixed in the very latest version of ucdn: https://github.com/grigorig/ucdn/commit/8af93f3089c2fe3edff004a9be01ed8c3a4320d5 | 20:36.21 |
| | tor8 (last for the logs): if I update to that version of ucdn.[ch] and unicodedata_db.h then the chinese characters are rendered on screen and e.g. http://www.unicode.org/charts/PDF/U4E00.pdf is indeed searchable. | 20:40.05 |
| Robin_Watts | rayjj: Good luck tomorrow. | 23:01.48 |
| | Helen says "He's missing the meeting for that? He should take the laptop. I'm sure they have wifi." | 23:02.19 |
| fredross-perry | yet another ghostscript.com/~fred/gsproof-dev.apk. (1) views the current page, not the first page, in proofing mode, (2) only offers the proofing button for docs that can in fact be proofed. | 23:30.55 |
| rayjj | Robin_Watts: yeah, but did you tell her that it would be on video chat ?? ;-) | 23:36.45 |
| | Robin_Watts: and tomorrow is not the real issue -- it's the prep tonight. :-( | 23:38.04 |
| | Forward 1 day (to 2015/08/25)>>> | |
IRC Logs