IRC Logs

Log of #ghostscript at

 <<<Back 1 day (to 2013/07/28)2013/07/29 
paulgardiner tor7: ping09:23.27 
tor7 paulgardiner: mornin'09:23.39 
paulgardiner Hi. Did you get a chance to look at the two commits on paul/master?09:23.59 
tor7 paulgardiner: not yet. will look.09:24.16 
paulgardiner ta09:24.21 
tor7 paulgardiner: fontdescriptor /Name entry is deprecated since PDF 1.2 I believe09:26.55 
  just let me double check the spec09:27.04 
paulgardiner Would make sense since it seems unnecessary.09:27.28 
tor7 sorry, not font descriptor. Font dictionary /Name entry is optional since 1.109:28.59 
paulgardiner I'm happy to remove it. What do you reckon?09:29.45 
tor7 pdfref17 has a "Note: This entry is obsolescent and its unse is no longer recommended."09:30.43 
paulgardiner Okay. I'll remove that.09:31.02 
tor7 the "FIXME: it->ucs should be converted to the correct encoding" comment, shouldn't that read "it->gid" instead?09:32.09 
  size = trm.a won't work for 90 degree rotated text. use fz_matrix_expansion() to extract the scale factor.09:33.18 
paulgardiner Oh excellent. I realised I should be working out the expansion but didn't know we had a function for it.09:35.41 
  Robin_Watts: Hi. Where are you?09:40.24 
tor7 Robin_Watts: I thought you'd be far away from home by now...?09:40.40 
paulgardiner tor7: Just those three things to change?09:42.08 
tor7 paulgardiner: in the first patch, yes. the rest looks fine.09:42.23 
  paulgardiner: I'm not clear on what happens in pdf_set_free_text_annot_appearance()09:43.04 
paulgardiner Those are in the second I thought09:43.07 
tor7 just by looking at the header file09:43.14 
sebras tor7: paulgardiner: Robins account seems to have been disconnected, so I think this is a simple reconnect.09:43.16 
tor7 it says "set" in the name, but takes no arguments09:43.38 
paulgardiner I've called similar functions "update" elsewhere possibly.09:44.10 
tor7 sebras: so we're going to have ghost robin here for a few weeks then? ;)09:44.22 
paulgardiner Would that be better09:44.25 
tor7 paulgardiner: update would be better, yes09:44.40 
paulgardiner okay09:44.51 
tor7 the name would match the comment better then :)09:45.15 
  paulgardiner: FT_LOAD_NO_BITMAP | FT_LOAD_NO_HINTING | are impled by FT_LOAD_NO_SCALE so can be elided09:47.25 
  in layout_text()09:47.34 
paulgardiner Okay. Handy09:47.53 
tor7 fz_chartorune converts from utf8 to unicode (which is one step closer to WinAnsi than each byte of a utf-8 string separately)09:49.08 
  for the FIXME: convert str tfrom utf8 to WinAnsi09:49.18 
paulgardiner was hoping to leave that and sort it out in one go09:50.11 
tor7 that's fine09:50.16 
  just pointing out a function if you don't know it already :)09:50.40 
paulgardiner Right.09:51.02 
tor7 in pdf_set_free_text_annot_appearance you have a variable "dr" for holding the resource dictionary. what's the logic behind that name?09:51.31 
  elsewhere we've used "rdb" (which isn't a whole lot more logical)09:51.49 
  I assume get_font_info is an older function?09:52.23 
paulgardiner Yes, it's from the earlier forms work09:53.01 
  Passing dr in would make that part work for other types of fonts09:53.42 
tor7 so no line breaking in layout_text?09:53.48 
paulgardiner Although the whole thing would fail further on09:53.56 
tor7 ah, you use "dr" consistently in the forms code I take it?09:54.43 
paulgardiner I believe so.09:55.04 
tor7 in pdf_set_free_text_details you always create a new font? no attempt to reuse?09:55.59 
  and the same thing with the /Name entry of the font dictionary in there09:57.04 
paulgardiner Intending to add that later. i.e., look for a already existing usable font09:57.37 
tor7 alright.09:57.53 
  I'm thinking pdf_measure_text and layout_text ought to be very similar09:58.15 
paulgardiner although, pdf_set_free_text_details creates the font in the xobject resources, and that is recommended to have its own copy09:58.34 
tor7 do you mean that the xobject resources should have a unique copy of the font object?09:59.24 
  each xobject would have its own font then? that seems wasteful09:59.51 
paulgardiner Well, it should have its own reference to it, I guess10:00.21 
tor7 the /Resource dictionary should be unique, so the /F%d name would probably be unique to each xobject10:01.00 
paulgardiner I think sorting out that requires passing tow resources to the pdf device.10:01.12 
tor7 but I think we should share the actual Font and FontDescriptor objects10:01.13 
paulgardiner s/tow/two10:01.36 
tor7 do you mean to pass both the page and xobject resource dictionaries?10:02.07 
  I think the PDF interpreter only looks in the xobject resources if they exist, and only looks in the page resource dict if there isn't an xobject resource dictionary at all10:02.41 
  that was a long and convoluted sentence...10:02.57 
paulgardiner tor7: that sounds the correct thing to do10:03.16 
tor7 define "that"10:03.37 
  passing two resource dicts would be the wrong thing to do10:03.51 
  but you're hopefully referring to my previous statements :)10:04.04 
paulgardiner tor7: I meant pass in a resource that can be searched for already usable things in addition to the one that gets built up during the use of the device10:04.13 
  I think this was your and Robin's suggestion, in fact. :-)10:04.42 
tor7 oh right, a global "we've seen these resources before, use them from here" dictionary, but don't use the actual dictionary in the pdf10:04.55 
paulgardiner Yep10:05.04 
tor7 right. yes. I think we discussed that a week or two back, yes.10:05.16 
paulgardiner But I didn't want to do that yet seeing as I'm just creating simple base14s10:05.30 
tor7 fair enough10:05.37 
  I was (as part of that) also advocating just looking through an existing resource dictionary (a regular one) for matching font descriptors10:06.07 
  but I guess that amounts to the same code being used10:06.21 
  so for later10:06.32 
paulgardiner Sorry, I didn't understand how the "also" suggestion differs from the previous one. 10:07.27 
tor7 look for existing object in page resources; not found, then look for existing object in global resource list and copy to page resources.10:08.09 
  same looking code, just in a different place and with a slightly different outcome10:08.35 
  use as is, in the first case. copy with a new name, in the second.10:08.58 
paulgardiner But still doesn't that require passing in a secpnd resource to the pdf device? Or can it find it from the fz_text obj10:09.05 
tor7 the pdf device has a resource dictionary attached to the page (or content stream) it's writing to10:09.51 
  doesn't it?10:09.59 
Lupo hi there. quick and fast question:10:10.08 
tor7 paulgardiner: pdf_device->resources10:10.36 
paulgardiner tor7: Yeah, but that's the one that gets things added to it10:10.51 
Lupo is it possible @ now to install gs for gimp on win8 to open .eps files?10:11.06 
tor7 paulgardiner: forget my ramblings, I'm confusing the two sides of the interface10:11.15 
paulgardiner tor7: Another idea was to preload that.10:11.19 
tor7 the pdf device does the right thing already10:11.23 
  (it reuses fonts it's seen on the same page already)10:11.38 
paulgardiner Ah right. yes10:11.51 
tor7 we may want to preseed the pdf_device->fonts list from a resource dictionary at setup time10:12.15 
paulgardiner Yeah. Various possibilities10:12.46 
tor7 I was (in a muddled state) thinking about how to reuse font objects for the text appearance annotations10:12.54 
  maybe all these places should have some "find me a good font descriptor for XYZ" function10:13.17 
paulgardiner tor7: Welcome to my world. :-)10:13.17 
tor7 Lupo: no idea, but if you mean real win8 (not the crippled winrt arm version) it ought to work out of the box just like on win7 and earlier.10:14.02 
  I don't know if gimp has done something special on win8, but if it's a "desktop" as opposed to "metro" app it should just work10:14.41 
  paulgardiner: anyway, I've commented on the things that need fixing. with those fixed it should be good to go.10:15.15 
  but we ought to be working on a non-master branch while the release candidate is settling10:15.28 
paulgardiner okay. Got a name in mind?10:17.33 
tor7 unmaster?10:18.33 
paulgardiner Another way would be to have a release branch. Makes little difference really10:23.09 
  Are you thinking we'd bring them together with merge or rebase?10:23.56 
tor7 merge, if there are any critical bugfixes on the release branch10:24.25 
  so we could do a release branch if we need to add bugfixes to the RC10:24.38 
  and keep working on master10:24.44 
paulgardiner yeah, sounds good10:25.43 
  So if no critical bug fixes needed, then eventually the rc will get also tagged as the final release. If there are critical bug fixes, we create a release branch at the rc point and merge all changes on that branch to master?10:28.08 
  tor7: repushed with your suggested changes, if you just want to check them over. Also pushed a previous branch with old version so that you can just diff if you like10:46.22 
tor7 paulgardiner: yes, that's the idea.10:53.12 
paulgardiner Ta10:53.24 
  Hang on, that was probably a reply to "So if no..."10:54.03 
tor7 paulgardiner: consider it a reply to both :)10:55.33 
paulgardiner :-)10:55.42 
  tor7: Wah! I just pushed one to many commits to golden. As anyone got "force access" to reset it back one? Or do I need to commit a reverse of the last?10:58.47 
tor7 paulgardiner: just push -f to golden10:59.12 
  there's no special access right required10:59.16 
paulgardiner Oh okay. Ta10:59.26 
tor7 if you do it fast enough, but it sometimes gives the cluster a hickup10:59.30 
  we've done it often enough that it should be routine procedure by now :) but I think only robin and marcosw have the know-how how to fix the cluster hickups11:00.13 
paulgardiner Phew! Hopefully that was fast enough.11:00.33 
tor7 at least it's early enough in the day that any cluster hickups won't affect too many people :)11:01.00 
paulgardiner the two rogue commits are still in the cluster queue11:01.50 
tor7 paulgardiner: yeah, they will be tested. the question is what happens when we push after and the history isn't linear anymore.11:02.50 
  I think one of the failure modes we had early on is that it retests every commit in the history :)11:03.22 
paulgardiner Hmmm quite11:03.25 
  Oh brilliant. I'm going to be popular11:03.43 
  ... not11:03.47 
  tor7: It would be useful if we could talk about the "text overrunning bounding box" problem later. Ping me when it's a good time. I know the cause now, but I can see two possible solutions and am unsure which is the best.11:29.01 
chrisl Lupo: Sorry, missed your question earlier: TBH, I've no idea. You're best bet would be to ask either the gimp Windows port maintainer, or the maintainer of the plugin.11:45.18 
tor7 paulgardiner: now is fine.12:07.10 
paulgardiner tor7: Right. Actually have three possible solutions. What's going on is that pdf_measure_text returns the exact bounding box of the text (NOT including the little gap between the initial writing pos and the start of the first char). I use that to derive the bounding rect for the annotation. Then when creating the appearance stream, I create text using the bottom left of the bounding rect as...12:14.04 
  ...the iniital writing pos.12:14.06 
  So the text is offset by the iniital gap.12:14.19 
tor7 ohhhh12:14.36 
  yes, that makes sense12:14.39 
paulgardiner Sol 1. zerp the bottom left of the rect before using it as the annotation rect.12:14.56 
  Sol 2. Change pdf_measure_text to just sum the advances.12:15.17 
tor7 doesn't the baseline also shift then?12:15.21 
paulgardiner Sol 3. In layout text, be more careful about positioning.12:15.39 
  I'm not sure why I'm not seeing probs with base line. Perhaps just because I didn't text with y or g etc. :-)12:16.14 
tor7 I'd expect that with the baseline at the bottom of the bounding rect the new text would be "face->descent" lower down on the page12:16.55 
paulgardiner Yeah, I expect so. I'll check that later12:18.03 
  Or now even.12:18.16 
tor7 my suggestion (given my limited understanding here) would be to make pdf_measure_text measure the advance widths only, and then use the font->ascent/descent to position the baseline and bounding box relative to each other12:19.12 
  so text->y would be derived from bbox->top + font->ascent12:19.42 
paulgardiner Ah good. I think that's my prefered solution too.12:19.44 
tor7 and text->x woul/d be bbox->left + text advance12:19.57 
  and baseline offsets for multiple lines would be face->height (or (descent+ascent)*1.2)12:22.43 
paulgardiner That should make text fit "nicely" in the bounding rect, with natural gaps all around12:22.50 
  tor7: oh okay. Useful to know.12:23.11 
tor7 and if you need to make a new bbox to adjust for the height, the lowest baseline + descent12:23.22 
  now, we probably ought to work on cleaning up the fz_font struct and functions around it. but that's something we can deal with later if you want.12:24.18 
paulgardiner Probably, because I'd like to get a first version of the signature stuff ASAP12:24.59 
tor7 preferably before we implement non-base14 fonts12:25.25 
  what we have now will do until then12:25.30 
paulgardiner Right. I'll give it a go.12:26.33 
tor7 given robin's (and yours, I guess) hate of fonts feel free to dump that bit of work on my desk12:27.25 
paulgardiner See how it goes. I don't hate fonts that much. It's just a case of reminding myself how it all works.12:28.47 
  tor7: I'm seeing descent = ascent = 0.0. Looks like these are present only if the Ascent and Descent are in the PDF file. Do I need to do an FT call? Also this needs to work for all fonts (not just base14) because pdf_measure_text is used by the forms code.12:45.41 
tor7 ah, yeah.12:46.32 
paulgardiner I'd imagine they are always present in the PDF file for Type 3s?12:47.03 
tor7 ascent/descent are part of the pdf_fontdesc struct, and I guess you don't have that?12:47.04 
paulgardiner I do have that12:47.22 
tor7 or if you do, we can set the pdf_fontdesc ascent/descent from the ft_face if they're not set in the PDF12:47.35 
paulgardiner Oh yeah. That would be good12:47.51 
tor7 at the end of pdf_load_font_descriptor12:47.52 
  if (fontdesc->ascent == 0) fontdesc->ascent = (float) face->ascent / face->units_per_EM;12:48.40 
paulgardiner Excellent. That easy!12:49.07 
tor7 though in theory, ascent and descent are required entries in a font descriptor12:51.38 
  but optional for type3 fonts12:51.45 
  descent is supposed to be negative according to the spec12:52.04 
  which is a bit of a gotcha12:52.18 
  I believe the freetype face->descent is positive12:52.27 
  I think we can safely delete cap_height and x_height (as we don't use them) and add in fontdesc->leading (which is in the spec, but we don't read)12:53.43 
  font_weight is also not read (it's newer in the spec than the code that reads fontdescriptors in mupdf... introduced in 1.5), but may be useful12:54.45 
  in fact, if you're updating this delete all but the entries we want to use12:55.45 
sybariten What would be the most active or suitable channel for discussion about postscript in general?13:22.45 
chrisl sybariten: I doubt there's a really active Postscript "venue" - not that people using it, and even fewer using it "properly"..... comp.lang.postscript has seen an increase in activity recently. Or stackoverflow13:26.08 
  s/not that/not that many13:26.21 
sybariten i see13:28.00 
chrisl sybariten: in general we don't mind discussing Postscript here, but we're not keen on being used as substitutes for reading the PLRM!13:28.32 
sybariten well i know nothing about PS really, but i just learned that i can (to my surprise) use negative values in "bounding box" to take an already rendered eps file, and give it more white space offset13:28.57 
chrisl sybariten: that's not really the correct way to do that - the bounding box should be the smallest rectangle enclosing the marks in the EPS.....13:30.14 
sybariten chrisl: i suspected it would not be considered very sophisticated!13:31.02 
chrisl It would be preferable for the calling PS code to move the origin appropriately so you get the contents positioned as required13:31.15 
sybariten But imagine this dilly of a pickle13:31.33 
  i have a system generating ps (eps) files of diagrams ... and for some reason, things are "too close to the left border". If you think of a Y axis, the numbers there get slightly cropped if they are of a bigger font, etc13:32.28 
  when inspected in adobe illustrator its appearent that the information is there, the characters arent actually "chopped off" ofcourse, its just that there are limits or boundaries that show them like this.13:33.08 
chrisl Hmm, I would say that your system is getting the bounding box incorrectly - given that the bounding box units are fairly course, it sounds like the system is rounding the numbers up instead of down - guessing, of course.13:34.12 
  Or is clamping the bounding box to zero and higher number13:34.56 
sybariten now, if i have " %%BoundingBox: 0 0 396 144 " and " 0 0 396 144 rectclip " set up already from the beginning....i'm thinking all drawing will originate from this, too13:35.40 
chrisl Erm, not exactly - but anything outside that will be clipped13:36.32 
  sybariten: note that the BoundingBox values and the rectclip are totally independent - it just happens, in this case, that the match13:37.54 
sybariten ok13:38.17 
chrisl In a "normal" Postscript interpreter, the BoundingBox is just comment, and is ignored. The rectclip is an operator, and will be acted upon13:38.50 
sybariten well, i dont knwo how to best explain this, but my idea was simply that first these boundaries are set up, and then a lot of _curves_ are drawn inside of them. And i thought it would be easier to inflict the offset to the boundaries, with a negative value, thant to translate all of the curve drawing, if you see what i mean? Then i'd have to change each value thats related to hwo a curve is 13:39.29 
chrisl sybariten: it really depends on how the Postscript is written: moving the curves *may* be a single operator..... "translate"13:41.00 
sybariten oh really? But i mean... there is a bunch of curcves in an image... something like "translate everything drawn hereafter, +10 and +10" or how do you mean?13:41.54 
chrisl sybariten: the translate operator moves the origin13:42.38 
sybariten hmmmm ok13:43.07 
chrisl sybariten: but as I said, if parts of the marks are being clipped, then the rectclip values, I would say, are wrong13:44.39 
sybariten ok13:45.58 
  yeah well this PS implementation is prolly far from perfect....13:46.10 
chrisl sybariten: so, how badly are the marks being clipped?13:46.36 
sybariten chrisl: i can show you the file if youre interested13:47.14 
  i find these issues a bit tricky to explain in words... sometimes13:47.27 
chrisl sybariten: if it's not too big, sure13:47.37 
sybariten 5 kilobytes i think13:47.42 
chrisl That's fine13:47.54 
sybariten whats the simplest file uploader today?13:54.16 
chrisl We usually use or you can e-mail it13:55.07 
sybariten hmm hmm but pastebin isnt optimal if you actually have a file, is it? You mean i'd paste all the contents then... hmmm14:00.42 
chrisl Like I said, e-mail works, too14:00.57 
marcosw1 paulgardiner: I noticed a problem with your latest cluster job, give five minutes to fix it and then you can repush.15:58.54 
paulgardiner marcosw1: Is that the one from c 10 mins ago?16:00.00 
marcosw1 yeah16:00.07 
  the bmpcmp job generated a "log file too big" error and the cluster job aborted16:00.25 
paulgardiner I don't know if it's related but earlier today I accidently pushed 3 commits when I intended 2 and had to reset back one.16:01.19 
marcosw1 any idea why the file tests_private__pdf__forms__v1.6__cafa_acaa_v2.0.mjs would generate millions of messages like this: warning: cannot encode character with code point 0x206d16:01.24 
paulgardiner marcosw1: Well a mistake in the code I've been working on lately could cause something like that.16:02.37 
  I'll test that file locally to see what's going on.16:02.54 
marcosw1 in the past we've had issues with cluster nodes filling their hard drives when warnings and/or debugging messages have caused large log files to be generated, so the cluster now checks for large log files and aborts the run. a better solution would be just to kill the job(s) which are the problem, but because of an internal limitation in the cluster code that's tricky.16:04.33 
  paulgardiner: commit 161e50f5cf is the one that shouldn't be there, correct? I'll roll the cluster back to d812f7 and let it re-run the two commits you intended to push.16:06.10 
paulgardiner That's the one.16:06.55 
  The cluster testing with that included would certainly explain the large number of warnings.16:07.59 
marcosw1 I really wish we used a version control system that didn't allow you to re-write history :-)16:08.57 
paulgardiner We could make that a policy. I could easily have pushed a reverse of the commit.16:10.38 
  And locally I could have a policy of trying to avoid ever putting anything on master that wasn't ready to commit, to try to ward off accidents16:11.49 
marcosw1 no, it doesn't happen enough to worry about, and like everybody else I like having a clean commit history. The problem is that the cluster code was written when we used svn, and I don't think it allowed mucking with the repository in this way, so it wasn't allowed for.16:12.04 
  well, I still haven't figured out how to correctly deal with the log file too big issue, but at least the cluster is back to being in sync with the mupdf repository (or at least it will be when the queued jobs are finished).16:13.49 
paulgardiner marcosw1: Brilliant. Thanks. And appologies for the cock up.16:14.31 
marcosw1 no worries.16:14.46 
paulgardiner Do you mean that the "log file too big" errors are still appearing?16:14.59 
marcosw1 paulgardiner: I don't think so.16:38.58 
paulgardiner marcosw1: Oh good. Okay to retry?16:39.36 
henrys marcosw1:I wonder if a live test directory can be exported for network mount somewhere?16:53.25 
mvrhel_laptop chrisl: so the program did not run on the arm surface17:08.21 
  I don't have any reasons why to help you though17:08.48 
chrisl mvrhel_laptop: no errors or such?17:09.50 
mvrhel_laptop no errors. it just said it could not do it. I tried as administrator17:10.22 
chrisl Hmm, maybe it doesn't have command prompt?17:10.43 
mvrhel_laptop of course I don't have the surface on me now, to give you the exact message17:10.55 
  if you want, I will do it again when I get back from coffee shop 17:11.15 
chrisl No, let's leave it. I wasn't exactly confident it would run anyway. We'll see whether the arch.h I've got in there works at some point ;-)17:12.02 
marcosw I'm going to take bugzilla down for a memory upgrade and installation of a ups. It should be back up in 15 minutes or so.18:09.48 
ray_laptop Darn. The trio sprintf appends a "0x" on the front of the number value. That breaks read mode fopen with memory based clists (I use %p format to print the address as a filename string). sscanf (filename, "%p", addr) stops at the 'x' and always returns 018:17.59 
  well, maybe it is just windows funkiness18:24.04 
tkamppeter Anyone knows when GS 9.08 will have FF and when it will get rel;eased?18:56.04 
  Ubuntu FF is end of August (29 AFAIR).18:56.28 
ray_laptop yep, that's the issue. linux AND trio write out %p with leading "0x" but windows writes %p the same format as %08x -- just the 8 hex characters19:06.19 
  so gxclmem.c broke when we switched to using the trio for sprintf :-(19:07.07 
  so does trio have an sscanf ?19:08.24 
ray_laptop goes to look19:08.28 
  guess it does. Adding gs_sscanf to our little group of gs*sprintf functions19:16.19 
mvrhel_laptop tkamppeter: chris is planning to create the release branch in the next couple days19:17.12 
  and of course I have a P1 segv bug dropped in my lap days before the release :(19:17.56 
  one of the new sumatra test files19:18.33 
tkamppeter mvrhel_laptop, I want to change one thing: I want to move the gstoraster CUPS filter from GS to cups-filters as now it will need libcupsfilters. Perhaps I also move gstopxl and all associated files, leaving only gdevcups.c and cups.mak in the cups/ directory of GS.19:20.37 
mvrhel_laptop tkamppeter: you probably should work with chrisl on this. he will be back online tomorrow your time (assuming you are in europe now)19:22.14 
tkamppeter mvrhel_laptop, OK, thanks.19:23.15 
mvrhel_laptop well Adobe generates an error with this file. I guess I need to see what is going on and make sure we generate an error before we get to a segb19:27.02 
  lunch time19:27.14 
ray_laptop wonders how any files that used pattern-clist mode were working. They use memory based clist19:28.21 
  my segfault with PCL and --saved-pages-test mode is fixed. Works as well as gs now. Next try and figure out which differences are real :-(20:56.35 
 Forward 1 day (to 2013/07/30)>>>