| | <<<Back 1 day (to 2012/06/20) | 2012/06/21 |
| kens | chrisl got a minute ? | 08:18.53 |
| chrisl | kens: yeh (sorry, getting a drink) | 08:25.48 |
| kens | NP | 08:25.55 |
| | If I send you a test file could you take a quick look a t it ? | 08:26.08 |
| chrisl | Go ahead | 08:26.15 |
| kens | On the way, ideas/questions in the email | 08:26.34 |
| | Bascially we seem to be treating the CIDFont differently to 'TrueType' CID Fonts as regards the CDevProc | 08:27.00 |
| | The 2 files which improve by ignoring the verticla metrics are both TrueType CIDFonts, the one that gets worse is a CIDFontType 0 font. | 08:27.47 |
| chrisl | Let me have a quick look before I make any bold statements :-) | 08:28.34 |
| kens | The regular CIDFont has a WMode of 1 and it seems we are respecting its vertical metrics | 08:28.36 |
| | Sure | 08:28.39 |
| | I was hoping you would remember where in the rendering/interpreting code to look since you've been there recently :-) | 08:29.06 |
| chrisl | I remember where to look, but can't remember the details..... | 08:30.06 |
| kens | Didn't expect you would, but I don't even know where to look.... | 08:30.24 |
| chrisl | So, the first important thing is that FAPI behaves the same as the old code | 08:30.59 |
| kens | Yes | 08:31.04 |
| | The file renders as (I believe) it is supposed to | 08:31.16 |
| | Which only happens if we respect the CDevProc vertical metrics | 08:31.36 |
| | (the font WMode is 1) | 08:31.45 |
| chrisl | Hmm, I don't see anything *after* the CDevProc being different - zsetcachedevice2() and gx_show_text_set_cache() are the relevant functions. I wonder if the metrics being given to teh CDevProc are different | 08:38.36 |
| kens | Its possible, I can see we are running the CDevProc, I haven't checked the return values. | 08:39.03 |
| chrisl | Hmm, nope, they look very nearly the same :-( | 08:43.37 |
| kens | Well rendering never goes through any of the 'glyph_info' procedures | 08:43.57 |
| chrisl | No, for this file, we get (most of?) the metrics from Freetype | 08:44.37 |
| kens | Somewhere thre must be a rule that determines whether we use the vertical metrics returned by CDevProc when WMode is 1 | 08:44.51 |
| | I presume ther rendering code does execute CDevProc ? | 08:45.12 |
| | Yes it does (just checked) | 08:46.26 |
| chrisl | Yes, definitely does that | 08:46.39 |
| kens | So in the case of this font, we respect the verticla metrics, in the case of our CIDFontType 11 font, we don't.... | 08:47.11 |
| | Or so it seems, maybe I'm missing something | 08:47.29 |
| chrisl | The CIDFontType 11 has a "real" CDevProc, too? | 08:48.01 |
| kens | Not sure. It certainly executes one | 08:48.20 |
| chrisl | Is it in a PDF or PS file? | 08:48.33 |
| kens | This is the file from #692365 | 08:48.35 |
| | Both are PostScript files | 08:48.43 |
| chrisl | Hmm, strange :-( | 08:49.01 |
| kens | The PDFs all work fine, exactly the same as before my changes | 08:49.02 |
| | I have 3 PS files that show differences | 08:49.14 |
| | one is #692365, the second is Bug692576.ps (which is improved) and the 3rd is Bug687846 which is wrong | 08:49.49 |
| | The 2 improved ones have CIDFontType 11 (TrueType), the regression has CIDFontType 0 | 08:50.15 |
| | All 3 fonts have WMode 1 | 08:50.35 |
| | It looks like GS is ignoring the vertical metrics for the CIDFOntType 11 fonts, and respecting them for the CIDFontType 0 | 08:51.01 |
| chrisl | So, the actual currentpoint movement comes from the text_params entry in the show enum - I wonder where that gets setup..... | 08:54.45 |
| kens | I gues that the CDevProc resutl modifies it ? | 08:55.14 |
| chrisl | <shrug> | 08:55.30 |
| | Ah, this is not a normal "show" operation..... | 08:58.27 |
| kens | no its an xshow | 08:58.50 |
| chrisl | I suspect that might be why we render it correctly..... | 09:00.50 |
| kens | Why does that make a difference ? | 09:01.11 |
| | We still must be applying the vertical metrics from CDevProc ? | 09:01.34 |
| chrisl | Yes, but then we partially ignore those metrics in favour of the currentpoint movement dictated by xshow | 09:02.15 |
| kens | If we weren't applying the vertical metric then I think it woudl still be wrong | 09:02.53 |
| | Yes, If I alter the '880' in teh CDevProc ot 0 the result is different | 09:04.28 |
| | When rendering | 09:04.40 |
| | So when rendering we are applying the vertical metrics from the CDevProc | 09:04.53 |
| chrisl | But not all of them, I think | 09:05.18 |
| kens | We aren't applying the horizontal metric (maybe) | 09:05.35 |
| | Changing the amkes no difference | 09:05.41 |
| | But the point is that, according to the spec if there is WMode 1 and no verticla metrics, we should treat the font as horizontal | 09:06.15 |
| | And indeed, for the TrueType cases, we apparently do | 09:06.25 |
| chrisl | What happens if you change the xshow to a show? | 09:06.48 |
| kens | let me see | 09:06.55 |
| | Looks OK here | 09:07.42 |
| | rendering | 09:07.48 |
| | It does seem to execute the CDevProc twice though | 09:08.08 |
| | Don't know why | 09:08.15 |
| chrisl | Once for each glyph | 09:08.24 |
| kens | No 4 tiems, twice for each glyph | 09:08.35 |
| | Yes, show and xshow render the same, but the CDevProc is executed twice for each glyph when using show | 09:09.37 |
| chrisl | Not in the current code | 09:09.42 |
| kens | My code is pretty nearly current | 09:09.52 |
| chrisl | Oh, hang on, I'd reverted my change to the source file..... | 09:10.06 |
| kens | I cna update to the most recetn but I doubt it will eb different | 09:10.07 |
| chrisl | No, for my show only executes CDevProc once per glyph | 09:10.58 |
| kens | In the test file I altered line 2357: /pdfxs {{xshow} stopped {pdfl1xs} if} bd | 09:11.00 |
| | to /pdfxs {{show} stopped {pdfl1xs} if} bd | 09:11.00 |
| | And I have also modified CDevProc iat line 4241 to : /CDevProc {(CDevProc) == flush pop pop pop pop pop 0 -1000 7 index 2 div 880} def | 09:11.44 |
| chrisl | shouldn't that be {pop show}? | 09:11.44 |
| kens | ah, maybe so | 09:11.53 |
| | Exactly the same.... | 09:12.22 |
| | no wait | 09:12.30 |
| chrisl | Well, you can't give show an array | 09:12.37 |
| kens | That's better, only 2 CDevProc now | 09:12.49 |
| | rendering still identical | 09:12.58 |
| chrisl | Okay, well, it's a slightly simpler debug, if nothing else...... | 09:13.23 |
| kens | What's *really* annoying is the name fo the font: GNFECB+MS-UIGothic-Identity-H | 09:15.01 |
| | It even says its horizontal.... | 09:15.08 |
| chrisl | Erm, if it's using Identity-H WMode should be 0 | 09:16.05 |
| kens | I know, but its not | 09:16.12 |
| | The test file extracts WMode form the font and prtins it as part of the debug at the ned | 09:16.37 |
| | end* | 09:16.40 |
| chrisl | Well, the spec is clear: the CMap WMode takes precedence over any sub-font WMode - very strange :-( | 09:18.47 |
| kens | It could be hacking the CMap ? | 09:19.17 |
| | just going through the prolog | 09:19.26 |
| | It seems to be calling our composefont and using our Identity-H | 09:19.57 |
| chrisl | It could be, or possibly "resetting" it after composefont - it's pretty horrid PS :-( | 09:20.10 |
| kens | I'm not clear on where teh WMode is coming form | 09:20.13 |
| chrisl | No, not clear at all | 09:20.26 |
| kens | after executing composefont it seems the font dictionary has no WMode entry | 09:21.21 |
| chrisl | Which is reasonable, since WMode defaults to 0 | 09:21.52 |
| kens | Weird... | 09:24.55 |
| | it calls st_ComposseFont which ends up calling composefont | 09:25.08 |
| | Then it pops the returned dict off the stack.... | 09:25.19 |
| | seems 'poitnless' | 09:25.25 |
| chrisl | It gets the font installed in the font directory | 09:25.42 |
| kens | Yes I suppose there's that | 09:25.57 |
| | Looks like it calls _pdfComposeFont | 09:26.27 |
| | To define the real font | 09:26.36 |
| chrisl | Which presumably does findfont, copies, then fiddles with the dictionary, and does definefont...... | 09:28.17 |
| kens | sort of, its a complex routine | 09:28.41 |
| | OK this is what does it: /N290 (GNFECB+MS-UIGothic-Identity-H) /Identity-H [ (GNFECB+MS-UIGothic) ] | 09:30.56 |
| | try that again | 09:31.07 |
| | "/N290 (GNFECB+MS-UIGothic-Identity-H) /Identity-H [ (GNFECB+MS-UIGothic) ] | 09:31.11 |
| | "/N290 (GNFECB+MS-UIGothic-Identity-H) /Identity-H [ (GNFECB+MS-UIGothic) ]" | 09:31.41 |
| | " /Adobe-Identity [ /Serif ] 1 TZzero" | 09:31.50 |
| | So we use composefont to create teh font. This uses the CMap WMode | 09:32.15 |
| | Then that '1' just before TZzero is the WMode that is *forced* into the font dictionary | 09:32.32 |
| chrisl | After the font has been defined? | 09:33.17 |
| kens | Its a copy | 09:33.26 |
| chrisl | Right | 09:33.38 |
| kens | It copies the orignal font, makes changes (including setting WMode) and the defines \a new font | 09:33.42 |
| | With a new name of course, in this case N290 | 09:34.28 |
| | So inessence we compose a horizontal fnt with a horizontal CMap and teh declare the result to be vertical.... | 09:35.05 |
| | What a great plan | 09:35.14 |
| chrisl | Remember I had problems with the CIDFont substitution code and pdfwrite - pdfwrite didn't like the way I redefined the ordering in a CIDFont? | 09:35.22 |
| kens | Umm, no I'd forgotten that | 09:35.35 |
| chrisl | Could this be something similar? | 09:35.47 |
| kens | I don't 'think' so | 09:35.59 |
| chrisl | I was grasping at straws :-) | 09:36.16 |
| kens | I'm still coming back to 'why does the rendering code respect the vertical metrics' ? | 09:36.27 |
| | I mean its a crap piece of Adobe code | 09:36.43 |
| | Oh, I wonder what happens if I set that to WMode ) :-) | 09:37.05 |
| | Ah, same as setting vertical metrics to 0 | 09:37.36 |
| Robin_Watts | Awesome quotes for the day: http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918 | 09:37.41 |
| chrisl | I was going to say: what happens if you used Identity-V? | 09:37.52 |
| kens | chrisl I could try that, but it still won't make any difference to pdfwrite | 09:38.12 |
| | Robin_Watts : touched a nerve there I see :-) | 09:38.41 |
| chrisl | Gosh, Linus being polite - he's even more funny when he's rude ;-) | 09:39.30 |
| kens | I see he has hte same opinion of Computer Scientists as me :-) | 09:41.21 |
| chrisl | I think that comes partly (largely?) from his experience of Tannenbaum and Minix | 09:41.58 |
| ghostgum | Spike Milligan was asked during an interview when his record would be released. "Released?" he said, "It will have to escape!" | 09:44.54 |
| | RedMon 1.9 has just escaped. | 09:44.59 |
| kens | chrisl if I set the WMode to 0 in the test file, then teh result is not the same as pdfwrite, but the parntheses are now inconsistnet with teh rest of the file :-) | 09:45.58 |
| | Well, it seems to me that GS is respecting the vertical metrics when the font is a CIDFontType 0 and we execute a CDevproc (and WMode is 1), so I'm going to implement that too. | 09:47.15 |
| | ah, RedMon 1.9, not RedHat I must learn to read.... | 09:50.02 |
| | THanks ghostgum | 09:50.07 |
| | Is there a web site anywhere I can go to look at the release ? | 09:50.55 |
| ghostgum | http://pages.cs.wisc.edu/~ghost/redmon/index.htm | 09:51.17 |
| kens | Thanks :-) | 09:51.28 |
| | Windows 7 suport, cool. Just in time for WIndows 8 ;-) | 09:52.07 |
| kens | hopes windows 8 won't change that... | 09:52.16 |
| ghostgum | Unzip redmon19.zip, unzip src.zip, read src/changes.txt | 09:52.22 |
| | RedMon is expected to *not* work with Windows 8. | 09:52.43 |
| kens | Along with everything else | 09:52.58 |
| ghostgum | Microsoft says third party port monitors are not supported on Windows 8. But I haven't test yet and it isn't clear whether they won't work with v4 printer drivers, or won't work with v3 (pre Windows 8) printer drivers. | 09:53.40 |
| kens | Oh great, lock another part of the OS :-( | 09:53.56 |
| ghostgum | If you want to capture the output of a printer driver, then it appears you need to implement the capture in the printer driver. | 09:55.47 |
| kens | :-( | 09:56.03 |
| | Well I don't think we're going to get into writing PostScript drivers. | 09:56.18 |
| | So its back to 'watched folders' for the future. | 09:56.47 |
| | Unless, of course, Windows 8 wis as well received as Vista was | 09:57.06 |
| chrisl | kens: any idea what the graphics state "root_font" entry is all about? | 09:59.04 |
| kens | chrisl absolutely none, I did run across it and wondered myself | 09:59.27 |
| chrisl | I can only see it being set to the same as the "font" entry, so it seems redundant | 10:00.14 |
| kens | chrisl I think its time to drop the problem. Its fairly clear that GS is respecting the vertical metrics from CDevProc *when* the font is a regular CIDFont, and not when its a TrueType font. I'm implementing that and it looks OK at the moment | 10:00.35 |
| ghostgum | I haven't investigated "XPS print path filters". It might provide a way that still works on Windows 8. | 10:00.36 |
| kens | NB I still check for the /W2 and friends and if those are present, we still use them. | 10:01.09 |
| chrisl | kens: I guess so, but I'd really like to know *how* it's doing that..... | 10:01.18 |
| kens | chrisl me too, but the fact that altering the values makes the file behave differently is pretty good evidence :-) | 10:03.27 |
| chrisl | I guess so..... | 10:04.08 |
| kens | Just starting a new test, lets see what breaks this time.... | 10:04.12 |
| | Still got to find out why the parntheses are wrong of course. | 10:07.16 |
| chrisl | Hmmm, well, your test file shows "font" and "root_font" as being different - also shows root_font with WMode 1, and font with WMode 0...... | 10:08.28 |
| kens | That suggest root_font is the parent and font is the subsidiary | 10:08.48 |
| chrisl | Yes, no idea where it's being set, though...... | 10:09.07 |
| kens | THe code in teh PS file only changes WMode in the parent font | 10:09.08 |
| chrisl | Then the font we actually pass into zchar_set_cache() has wmode 0..... | 10:10.52 |
| kens | Loks like gs_makefont in zcfont.c | 10:11.00 |
| | called fro cshow_continue | 10:11.20 |
| | Oops no | 10:11.32 |
| | Gets used there to 'construct a scaled version of the leaf font' | 10:12.28 |
| | The decendant presumably | 10:12.36 |
| | It does get set in gs_setfont | 10:13.04 |
| | pgs->font = pgs->root_font = pfont | 10:13.23 |
| | Possibly when we select a descendant that changes pgs->font | 10:13.37 |
| chrisl | Yep, probably that's it | 10:13.49 |
| kens | Can't see any other places | 10:14.32 |
| kens | remembers that the parentheses problem is probably the missing W and W2 entries | 10:15.42 |
| | coffee time | 10:16.21 |
| chrisl | kens: Something is confusing me...... | 10:25.53 |
| kens | Me too :-) | 10:26.04 |
| chrisl | Can you have a quick look at psi/zcharout.c line ~80 | 10:26.31 |
| kens | one second | 10:26.39 |
| | yes ? | 10:26.58 |
| | given a base font, gets the parent font | 10:27.10 |
| chrisl | But we're looking for a metrics dictionary | 10:27.29 |
| kens | yes | 10:27.35 |
| | I think (despite teh comment) this is stored in teh roginal font dictionary, not teh base ofnt | 10:27.53 |
| chrisl | Metrics are stored in he base font, aren't they? | 10:27.54 |
| kens | chrisl I thnk not | 10:28.07 |
| | I think you need the original font dictionary | 10:28.14 |
| | let me check teh struct | 10:28.19 |
| chrisl | What happens if you have multiple descendants? | 10:28.28 |
| kens | This isn't descendants, its a *base* font which si a GS thing | 10:28.45 |
| | See gxfont.h | 10:29.20 |
| chrisl | Great way to confuse people :-( | 10:29.39 |
| kens | In amongst all the usual horrible macros | 10:29.42 |
| | chrisl yes, and pdfwrite has its own version too, and its different :-) | 10:29.59 |
| | Yes the base_font is a GS structure and it doesn't have an metrics in it | 10:30.29 |
| chrisl | I guess it's because it predates composite fonts, so the "base font" and "parent font" weren't names in use back then | 10:30.46 |
| kens | So to check the metrics you need to retrieve the original font dictionary and look in that | 10:30.48 |
| | chrisl yes I guess that's probably why | 10:31.00 |
| paulgardiner | Robin_Watts, tor8: there are a couple of commits on my casper forms branch that could do with a check over, if one of you has time. | 10:31.48 |
| kens | As far as I remember the base_font structure is an abstraction (with the useful bits) of the original font dict whcih can be passed around in C | 10:31.49 |
| chrisl | kens: no, data.parent *is* the Type 0 font..... | 10:33.31 |
| kens | well its been a while... | 10:33.54 |
| chrisl | psi/zfcid0.c line 513 - so we are looking for Metrics in the Type 0 font | 10:34.30 |
| kens | Hmm, not sure whether that's right or not | 10:34.53 |
| kens | goes to PLRM | 10:35.44 |
| | p 373 suggest that is correct, as the Metrcis entry is in a CIDFOntTypoe 0 font | 10:36.48 |
| chrisl | Hmm, I thought metrics had to be with the glyph descriptions - oh well..... | 10:37.23 |
| kens | Hmm, though of course that is teh *CIDFont* not the instance | 10:37.24 |
| | The entries in an FDArray dictionary don't contain metrics | 10:37.59 |
| | (Table 5.14) | 10:38.06 |
| tor8 | paulgardiner: "Forms: permit annotations with no appearance stream" looks okay to me | 10:39.39 |
| chrisl | kens: one thing that might influence your current problem: psi/zfapi.c line 2572 | 10:39.59 |
| paulgardiner | Thanks Tor | 10:40.12 |
| tor8 | paulgardiner: "Forms: implement the RestForm action" looks easy enough at a glance, but you misspelled reset in the commit message :) I'd also indent the tertiary expressin in pdf_to_str_buf differently (just slap it on one line and let it be too long) | 10:41.13 |
| paulgardiner | Oh ok. can easily sort those | 10:41.50 |
| | tor8: Done. Can you push then for me? I don't have access to the main repo. | 10:45.04 |
| kens | chrisl aha.... | 10:45.34 |
| | So if it is type 1 font data we replace the metrics and if it isn't we do 'something else' | 10:46.32 |
| | Depending on the presence of a Metrics2 dictioanry | 10:46.50 |
| | ah, yes, we set bVertical to alse | 10:47.23 |
| | But if its type 1 it looks like we repsect the metrcis | 10:47.41 |
| | Looks like the smoking gnu | 10:47.48 |
| | Actually, no its not that either :-( | 10:49.31 |
| | Anyway, ny test results are good | 10:50.41 |
| | can have a look at my bmpcmp if you want, tehre's only one file different and its a progression | 10:50.57 |
| | So, back to parentheses | 10:51.29 |
| chrisl | kens: yeh, the thing I don't follow is that none of that should influence what happens *after* the CDevProc | 10:52.01 |
| kens | chrisl it doesn't actulaly seem to make any difference anyway | 10:52.18 |
| | But I'm convinced that something, somewhere, does | 10:52.35 |
| chrisl | Sure, actually, my feeling is that we should only be probing the TTF data directly if it's a *substitute* font, not a downloaded one - but I've no solid evidence to support that | 10:53.28 |
| kens | It seems to do that in teh clause below where ti checks font_file_path | 10:54.26 |
| chrisl | Yes, that's what I added for this current problem to get it render correctly - we don't want to "fake" metrics for downloaded fonts | 10:55.26 |
| kens | Ah, right | 10:55.39 |
| | I'm not sure what's going on above tha, the MetricsCOunt and 'l' | 10:56.06 |
| chrisl | MetricsCount tells us if we have metrics and whether they are only horizontal, or both - "l" is the just the length of the data, so we don't read past the end of the buffer for a broken font | 10:57.32 |
| kens | OK so we only replace the metrics in there if we actually have some metrics in teh font | 10:57.54 |
| chrisl | Yes | 10:58.09 |
| kens | Well, it kind of makes sense, but I'm not sure | 10:58.25 |
| chrisl | Personally, I think the matrics from the PS dictionary should take precedence, if they exist | 10:58.54 |
| | s/matrics/metrics | 10:59.02 |
| kens | Yes, posibly true, but this is a TT font, so who knows ? | 10:59.21 |
| chrisl | That covers both TT *and* Type 42 | 10:59.37 |
| | (and CIDType 2) | 10:59.53 |
| kens | Yes, I meant that | 10:59.56 |
| chrisl | Anyway, unless someone fins a problem with it, I'm not changing it! | 11:00.32 |
| kens | I think that's hte best way :-) | 11:00.42 |
| tor8 | paulgardiner: pushed. | 11:20.30 |
| kens | lunches | 11:23.44 |
| Robin_Watts | tor8: really pushed? | 12:05.33 |
| tor8 | Robin_Watts: huh. I was certain I had... | 12:06.53 |
| h3llh0und | hi, is there a way to detect if a version of ghostscript is already installed? | 12:14.31 |
| kens | you could try running it | 12:14.42 |
| | On what OS ? | 12:14.55 |
| h3llh0und | Windows | 12:15.11 |
| kens | Well it depends what you mena by 'installed' I guess. | 12:15.36 |
| | WHy do you need to know ? | 12:15.43 |
| h3llh0und | i want to inform the user that he needs to install ghostscript | 12:16.06 |
| | if he hasnt | 12:16.15 |
| | but i cant find a way to detect that | 12:16.35 |
| kens | Presumably because you application relies upon the preence of Ghostscript ? | 12:16.40 |
| Robin_Watts | tor8: golden/forms is on 6884949 as far as I can tell. | 12:17.50 |
| | paul/forms is 4 ahead of that. | 12:17.58 |
| | I have put built versions of the v8 libs for windows/linux32/linux64 in http://ghostscript.com/~robin/ | 12:18.49 |
| | I guess I should do macos too. | 12:19.10 |
| tor8 | I see golden/forms at 9142994 for me. double check? | 12:19.36 |
| | Robin_Watts: yikes. big tarballs :( | 12:20.13 |
| Robin_Watts | me too now. | 12:20.50 |
| | sorry/ | 12:21.08 |
| | yes, big tarballs. | 12:21.15 |
| kens | Hmm, seems my question scared him off..... | 12:21.51 |
| ghostgum | Too late for h3llh0und, but you can tell which version of GS is installed by looking at the registry. There is some code in GSview to get a list of the installed versions, with a less restrictive licence than the rest of GSview srcwin/gvwgsver.c | 12:35.44 |
| kens | ghostgum : yes, I was going to suggets that, or environment variables, to him | 12:36.08 |
| | With a mention that GS doesn't have to be 'installed' like that | 12:36.32 |
| ghostgum | True, it can be run "portable" now. | 12:36.50 |
| kens | But for his purposes I suspect that would be good enough | 12:36.53 |
| paulgardiner | Robin_Watts, tor8: there's another trivial little patch up on my repo, if one of you has a free moment. | 12:55.31 |
| Robin_Watts | paulgardiner: OK... | 12:56.42 |
| | Is that an "it'll get us further than we go at the moment" patch? | 12:57.11 |
| | or a proper patch? | 12:57.16 |
| paulgardiner | Proper patch. | 12:57.28 |
| Robin_Watts | hmm. nice. | 12:57.47 |
| paulgardiner | We need only add javascript for uitility stuff. No need to wire it up to the C | 12:58.03 |
| Robin_Watts | Done. | 12:58.44 |
| paulgardiner | Ta | 12:58.48 |
| Robin_Watts | np. | 12:58.53 |
| | I hate xcode. | 13:28.03 |
| sebras | Robin_Watts: vim will welcome you. ;) | 13:34.19 |
| Robin_Watts | JUST DO A F**KING RELEASE AND DEBUG BUILD. | 13:34.44 |
| | I mean, how many layers of abstracted crap do they need to lay on top? | 13:35.06 |
| | This project clearly has configurations for Debug and Release (as under "Add configuration" it offers to copy either of them) | 13:37.08 |
| | But how can I set the current configuration? | 13:37.18 |
| tor8 | Robin_Watts: Xcode 4? | 13:39.17 |
| | if yes: there is no 'current' configuration -- only different "build action presets" you can invoke | 13:39.54 |
| | it's a right bloody useless mess | 13:40.03 |
| Robin_Watts | I mean, this is apple. If they do nothing else, you expect them to produce something that's easy to use. | 13:40.37 |
| | They seem to have gone from "Principle of Least Surprise" to "Principle of Greatest WTF" | 13:41.15 |
| paulgardiner | If you ever do understand the underlying principle they are working to, please explain it to me. | 13:41.47 |
| | ... although maybe you just have. | 13:42.06 |
| tor8 | Robin_Watts: you obviously haven't had to use iTunes ;) | 13:44.12 |
| | their principle of greatest WTF started a long time ago... | 13:44.30 |
| Robin_Watts | ok, so gyp produces xcode projects that only seem to mention "Debug" not "Release", so I can't even use the command line. | 13:49.27 |
| | are we using clang these days on macos ? | 13:49.33 |
| | I'm going to drop back to using the linux makefiles on macos. | 13:49.57 |
| tor8 | Robin_Watts: not by default, but I do sometimes run make CC=clang on mac | 13:50.50 |
| paulgardiner | Robin_Watts, tor8: another tiny patch on paul/forms | 14:17.59 |
| Robin_Watts | ok... | 14:18.47 |
| | looks much more convincing now :) | 14:19.33 |
| | Were the 2's previously fudge factors ? | 14:19.41 |
| paulgardiner | I think using 2 was wrong. And there's sort of a hidden 1 instead in using rect.y1 | 14:20.52 |
| Robin_Watts | pushed. | 14:21.13 |
| paulgardiner | Ta | 14:21.17 |
| Robin_Watts | np. | 14:21.20 |
| henrys | chrisl:I think we should do the contrib directory also, everything should be GPL or less restrictive, if folks complain we'll remove it. | 15:49.56 |
| | s/folks/authors/ | 15:50.10 |
| chrisl | henrys: I thought contrib was all GPL already? | 15:50.25 |
| henrys | we have some files that have both GPL and AFPL the AFPL should be removed, I'm still going through them. | 15:51.20 |
| chrisl | henrys: Okay, you can leave it to me, I'll look at it tomorrow, or next week | 15:51.49 |
| henrys | okay sounds good. | 15:52.39 |
| chrisl | henrys: to be honest, I've been considering a more "proactive" attitude on contrib - like stating publicly that any contrib device without a maintainer will be removed | 15:53.02 |
| henrys | it would be interesting to know if these devices are actually being used, every time I look at one I find something glaringly wrong with it. | 15:55.38 |
| chrisl | What I thought was, contact the identifiable authors, put an announcement in the 9.06 release notes, maybe put an announcement on sourceforge, google code, freshmeat etc, if no one has responded by the run up to the following release, the device gets canned. | 15:57.18 |
| henrys | well I'd be concerned that a device works perfectly fine for a lot of users and doesn't have a maintainer. | 15:59.24 |
| chrisl | OKay. It's just that there are legal ramifications to changing licenses unilaterally..... | 16:00.18 |
| henrys | actually the only problem I found so far is the the dual GPL and AFPL gdevbjc.c | 16:01.31 |
| chrisl | I thought we had a bjc device in base.... | 16:03.40 |
| henrys | and gdevp201.c and a few others have weird licenses: Ghostcript Public License .. hmph | 16:03.52 |
| | if so it can be removed. | 16:04.06 |
| chrisl | It may be that there different species of the cannon bj printers, though..... | 16:05.27 |
| | kens: ping | 16:08.22 |
| kens | chrisl pong quickly | 16:08.31 |
| chrisl | The rendering code isn't ignoring the vertical metrics in your test job | 16:08.47 |
| kens | BTW the reason the widths are not emitted in the /W and /W2 attays is because htey are the same as the defaults. | 16:08.56 |
| | chrisl no, its applying them OK thast's the pont | 16:09.06 |
| | But why ? | 16:09.23 |
| | Its a font with no Mertrics or Metrics2 and has a Wmode of 1, so we should ignore teh WMode and only apply the horizontal metrics ? | 16:09.50 |
| | I htought that was what the PLRM was saying | 16:10.12 |
| chrisl | Something odd is that the font matrix for the type 0 font is rotated 90 degrees | 16:10.40 |
| kens | That is indeed strange | 16:10.52 |
| | But for the latin text it makes sense | 16:11.08 |
| | As it is written vertically | 16:11.17 |
| | The Kanji text looks upright though, not rotated | 16:11.35 |
| chrisl | Yes, because the CTM is rotated 90 degrees the other way..... | 16:12.04 |
| kens | ROFL | 16:12.11 |
| | What's the point of that ? | 16:12.21 |
| chrisl | <shurg> | 16:12.30 |
| | or even <shrug> | 16:12.43 |
| kens | Huh, been trying to work out why the same glyph gets drawn mutliple times, I htin kits the stupid artificial bold stuff in the file. | 16:13.15 |
| chrisl | Yes, I noticed that | 16:13.49 |
| kens | Going to have to remove that tomorrow, its making it hard to see what's happening | 16:14.18 |
| chrisl | Is this in the customer file? | 16:14.38 |
| kens | No, your much reduced 3 letter one | 16:14.52 |
| | I think | 16:15.04 |
| chrisl | Oh, I thought I'd removed the artificial boldening in that | 16:15.15 |
| kens | Oh good, now I'm getting /.notdefs instead of parentheses | 16:15.27 |
| | Must have broken something somewhere | 16:15.45 |
| chrisl | but are they in the right place? ;-) | 16:15.52 |
| kens | Hard to tell :-) | 16:15.58 |
| | OK got to go, night all | 16:18.26 |
| chrisl | 'nite kens | 16:18.35 |
| Robin_Watts | Hi mvrhel_laptop. How's Stephanie ? | 16:22.58 |
| mvrhel_laptop | much better. i think she is heading home today. I am at the hospital now | 16:23.19 |
| Robin_Watts | that's excellent new. | 16:23.42 |
| | news. | 16:23.43 |
| henrys | mvrhel_laptop:so they did the surgery? | 16:23.44 |
| Robin_Watts | You tried to talk to me last night, and I missed you... | 16:23.57 |
| mvrhel_laptop | oh. I think Scott wanted to talk to you about what were new features in mupdf | 16:24.32 |
| | henrys: Yes they did it yesterday at noon | 16:24.45 |
| Robin_Watts | ah, ok. I got an email from him. | 16:24.52 |
| mvrhel_laptop | ok that is what I told him to do | 16:25.16 |
| | oh | 16:51.49 |
| | Robin_Watts | 16:51.52 |
| Robin_Watts | chariots chariots | 16:52.04 |
| | (One day, I'll find someone that understands that meme) | 16:52.21 |
| mvrhel_laptop | here I have been trying to figure out why my copy_alpha changes are having problems with Bug692217.pdf.psdcmyk.300 and I see that this occurs in the head | 16:52.32 |
| | when was this introduced? | 16:52.38 |
| Robin_Watts | When was what introduced? | 16:53.11 |
| mvrhel_laptop | tests_private/comparefiles/Bug692217.pdf.psdcmyk.300.1 henrysx6 Seg_Fault | 16:53.24 |
| | this was started with some commit | 16:53.31 |
| Robin_Watts | ah, right. | 16:53.36 |
| mvrhel_laptop | It is due to a pattern-clist/transparency color info mix-up | 16:53.54 |
| | I have the file somewhat reduced but is it still crazy complex | 16:54.29 |
| Robin_Watts | I see SEGVs going back to the start of june at least | 16:55.26 |
| | start of may... | 16:56.09 |
| | 13th april is the earliest one I can find. | 16:56.44 |
| | 34b74d7bb34390ad75ba8ca52b6bd5e94e85a51e | 16:56.57 |
| | which is a bmpcmp change. | 16:57.52 |
| | so that smells like an indeterminism to me. | 16:58.08 |
| mvrhel_laptop | ok. Have to wheel stephanie out of hospital now. bbiaw | 17:03.13 |
| henrys | wish her well for us. | 17:04.49 |
| | chrisl_away:sort of thinking about your warning about changing licenses I think you are right we shouldn't, why not just remove anything that doesn't have a gpl license and send them an email. | 17:19.00 |
| mvrhel_laptop | back... waiting for final paper work | 17:21.25 |
| henrys | did you give her the right change for the bus? Still laughing about Robin_Watts' joke yesterday. | 17:22.15 |
| mvrhel_laptop | oh that is a good idea... | 17:22.34 |
| | she can't drive for a week | 17:22.50 |
| | ;) | 17:23.03 |
| Robin_Watts | Buy her a bus pass instead of chocolates. | 17:23.09 |
| mvrhel_laptop | Robin_Watts: what commit was the big one that was hl color for psdcmyk? | 17:24.11 |
| | I wonder if that started the problem | 17:24.17 |
| Robin_Watts | mvrhel_laptop: 60640ae ? | 17:25.15 |
| mvrhel_laptop | or a possible softmask fix could have done it too. the issue is due to a color space change occurring with a soft mask | 17:25.19 |
| Robin_Watts | April 27th. | 17:25.36 |
| | so that's after I see the first crash. | 17:26.00 |
| | Something around about April 13th I reckon. | 17:26.23 |
| mvrhel_laptop | regression34b74d7bb34390ad75ba8ca52b6bd5e94e85a51e | 17:28.10 |
| | oh that is the bmpcmp one | 17:28.23 |
| Robin_Watts | right, that's what I found by searching in my mail folder. | 17:29.08 |
| | and that only touched bmpcmp.c, so it can't be guilty. | 17:29.25 |
| mvrhel_laptop | weird | 17:29.31 |
| Robin_Watts | This may be a long standing indeterminism that is only being tickled recently due to an unrelated change ? | 17:30.06 |
| mvrhel_laptop | right | 17:30.15 |
| Robin_Watts | Open it as a bug and then ignore it for your current stuff? It's not like you're making it any worse. | 17:30.31 |
| mvrhel_laptop | right | 17:30.39 |
| | ok. I will beat on the few other ones that I have | 17:31.02 |
| | ok. now I am leaving.... | 17:40.47 |
| Robin_Watts | tor8: ping | 18:16.14 |
| | I think MuPDF can fail to lex any string over 256 chars long in certain circumstances. | 18:21.18 |
| Janka | Hi | 18:22.18 |
| | I maintain a linux distribution for an "embedded" POS system. It has PDF generation so users can download PDFs woth their web browser and print it on their office PC. Now there are some users which do not have an office PC and they want to print directly the PDF from the POS. I know ghostscript can convert PDF to PS or raster, which various printer drivers - I currently prefer Brother... | 18:29.08 |
| | ...HL5250DN and similar printers for the application - accept as input. So I think I have to set up a ghostscript package for my distribution. | 18:29.10 |
| | Question: Which are the parts of ghostscript I need to do this? | 18:29.34 |
| Robin_Watts | Janka: You need Ghostscript. | 18:35.54 |
| | All of ghostscript, but not the larger GhostPDL package, of which ghostscript is a part. | 18:36.16 |
| Janka | Ok, more specific: If the printer driver has ps input, do I need fonts? | 18:37.31 |
| Robin_Watts | You can go from PDF -> PS with gs, which will use some of the fonts in your printer. | 18:51.00 |
| | but depending on the number of fonts your printer has, you may find that PDF assumes the presence of some that your printer doesn't have (I'm no expert on this - try again earlier tomorrow and speak to kens) | 18:51.56 |
| | But gs has all the fonts you should need in it. | 18:52.06 |
| Janka | Robin_Watts: I generate the PDF with pdflatex, so I can control the fonts used. Currently it has "helvet" and "courier" package of LaTeX. | 19:38.02 |
| | (I know I could go with plain LaTeX and dvips, but I'd still need pdf generation for >50% of the users. And, LaTeX has it's own fonts, which is roughly the same problem.) | 19:39.18 |
| | Another question: Which time is "earlier tomorrow"? I'm at CEST. | 19:42.20 |
| Robin_Watts | kens works UK time. | 20:14.35 |
| Janka | Thanks! I will try it tomorrow. | 20:44.31 |
| Scott-san | Can anyone tell me if we've had any support needs brought to us by Garmin? Anything at all from Garmin? | 20:48.18 |
| Janka | Oh, before I forget: The irc link on http://www.ghostscript.com/ is broken. It reads irc://freenode.net/ghostscript, but it has to be irc://irc.freenode.net/ghostscript | 21:28.08 |
| sebras | Robin_Watts tor8: sebras/master has a insignificant one. | 23:30.13 |
| | do you mind if I add a new make target named "third"? the intent would be to be able to build the third-party stuff without building any of the mupdf-stuff and then completing by a normal make afterwards. this would be useful for easily separating compiler warnings for third from mupdf (make -j10 third; clear; make -j1) or for running clangs scan-build only on relevant files. | 23:51.43 |
| | in case you do there is another patch at sebras/master for you. | 23:57.11 |
| | Forward 1 day (to 2012/06/22)>>> | |
IRC Logs