| | <<<Back 1 day (to 2014/10/28) | 20141029 |
| dinamic_ | avih, good to hear | 00:04.07 |
| | avih, do you just delete or delete and inserts elements using splice ? | 00:07.29 |
| avih | dinamic: just insert... | 00:07.52 |
| | dinamic_: ^ | 00:08.11 |
| | it's it's likely that the index at which i insert is either 0 of array.length, though not necessarily (i didn't try to reduce the test case.. spent way too much time on it) | 00:09.07 |
| | and it's also likely that the array length is 0 or 1 to begin with | 00:10.32 |
| dinamic_ | ah, ok... | 00:10.57 |
| avih | (it's an implementation of set/clear Timeout/Interval, so the array if of the handlers, and it starts empty) | 00:11.24 |
| | (obviously i also need to delete items from the array, but it crashed even if i disabled the deletion code) | 00:14.20 |
| ruff | sup, guys, is here anyone alive?) | 09:12.38 |
| chrisl | reboots..... | 09:39.31 |
| Robin_Watts_ | ruff: Yes, there are people here. In general on irc, don't ask to ask a question, just ask the question | 10:22.45 |
| ruff | ok. is there any way to scale pdf not proportional? -dPDFFitPage leaves blank space | 10:31.32 |
| chrisl | ruff: by white space, do you mean the margins? | 10:34.39 |
| Robin_Watts_ | ruff: When rendering to what? | 10:37.00 |
| ruff | chrisl: -dPDFFitPage fits page, but i need to fill the page | 10:37.28 |
| Robin_Watts_ | If you're wanting to render a PDF to a bitmap, and have better control of the output size than gs can give you, you may want to look at mupdf and mudraw instead. | 10:37.58 |
| chrisl | ruff: so PDFFitPage will scale down, but doesn't scale up - hmm | 10:38.17 |
| ruff | Robin_Watts_, nope, i have some eps,pdf,ai files as an input and have to convert them to pdf of special size, it doesn't matter what page size i have in input it should be scaled to resulting pdf | 10:41.02 |
| Robin_Watts_ | ruff: ah, mupdf is not an option for you then. | 10:41.21 |
| chrisl | ruff: so you are using the -dFIXEDMEDIA option? | 10:41.39 |
| ruff | gs -o \"$out_name\" -dDEVICEWIDTHPOINTS=".mm2points($width)." -dDEVICEHEIGHTPOINTS=".mm2points($height)." -dFIXEDMEDIA -dEPSCrop -dPDFFitPage -dFirstPage=1 -dLastPage=1 -sDEVICE=pdfwrite -sProcessColorModel=DeviceCMYK -sColorConversionStrategy=CMYK -sColorConversionStrategyForImages=CMYK \"$in_name\" | 10:43.17 |
| | i tried with and wo this option | 10:43.38 |
| chrisl | Is that for PDF input, then? | 10:44.16 |
| ruff | yep | 10:45.42 |
| chrisl | And, again I ask: is the white space you're talking about the margins? | 10:46.18 |
| | ruff: actually, this would probably be easier if you could make an example file available, with a command line and clear description of the problem | 10:49.58 |
| ruff | chrisl: input file https://cloud.mail.ru/public/f0431e513b8e%2Finput.pdf | 10:59.28 |
| | output https://cloud.mail.ru/public/31e7a80c749d%2Foutput.pdf | 10:59.45 |
| | i want the input file to be resized to dimensions of output file, the is that i can't achieve this | 11:01.11 |
| | command line is above | 11:02.16 |
| | expected this https://cloud.mail.ru/public/40b7842a35d9%2Fexpected_output.pdf | 11:07.52 |
| chrisl | Well, I can run your command line | 11:09.50 |
| | I mean I can't run your command line | 11:10.02 |
| | And your expected_output.pdf still has more whitespace around the markings than the original | 11:12.14 |
| ruff | gs -o output.pdf -dDEVICEWIDTHPOINTS=286 -dDEVICEHEIGHTPOINTS=607 -dFIXEDMEDIA -dEPSCrop -dPDFFitPage -dFirstPage=1 -dLastPage=1 -sDEVICE=pdfwrite -sProcessColorModel=DeviceCMYK -sColorConversionStrategy=CMYK -sColorConversionStrategyForImages=CMYK input.pdf | 11:13.36 |
| | try this | 11:13.49 |
| | i don't need to remove the whole white space | 11:14.07 |
| chrisl | ruff: there's some interactions here I don't fully understand, so you probably need to wait for kens to come back in an hour or two. He'll probably have more insight than I do (without me doing a *lot* of digging). | 11:20.01 |
| ruff | chrisl: ok, anyway thanks) | 11:22.19 |
| | i've made an illustrated explanation of my problem https://cloud.mail.ru/public/1c072c5ac94a%2Fexplanation.pdf | 11:37.50 |
| chrisl | ruff: I doubt you'll get that without hacking the PDF interpreter - we'll always retain the aspect ratio | 11:43.41 |
| tor8 | avih: did you find the problem with array.splice? | 12:22.24 |
| | it's a complicated function if you follow the spec, so there may very well be bugs in it | 12:22.48 |
| avih | tor8: i examined the implementation briefly, seemed ok to me (didn't read the spec but the implementation had just enough comments to explain what it tries to do). the only thing there which raised a flag was 'top - 3' at one place but i was too tired to try and figure out how it works exactly. FWIW, i tried a loop of 1000 splices where each adds 1 item at the sample REPL and it took way more than i expected it to (though the result looked ok) | 13:10.53 |
| rayjj | Robin_Watts_: I heard a report on the public radio this AM talking about 'cars with 4g (Audi A3 mentioned) and they discussed the "distracton factor" of text/call even when it is audio, BUT AT THE END THEY MENTIONED AN APP TO DISABLE THE PHONE WHEN YOU ENTER THE CAR | 14:50.47 |
| | Robin_Watts_: that sounds somewhat familiar ;-) | 14:51.07 |
| Robin_Watts_ | rayjj: That'll be a bluetooth thing, no doubt. | 14:51.23 |
| rayjj | mvrhel_laptop: also FYI | 14:51.24 |
| Robin_Watts_ | the smart thing about the Artifex solution is that it only disables it for the driver. | 14:51.58 |
| henrys | chrisl: scratching my head over yesterdays issue with -I and GS_LIB, it would seem a rom build should ignore the variables entirely and it's a bug ... not a discussion. But I might not understand something. | 16:29.40 |
| kens | But then if we build a ROM version of GS (like the standard Windows build) there's no way to override the resources wihtout rebuilding it without a ROM file system. I don't think that's a good idea. | 16:33.24 |
| | I often use -I to temporarily override the resources in my build while I debug stuff | 16:34.01 |
| henrys | kens: okay that's where I'm confused, I think that's a great idea. If you want configurability don't use COMPILE_INITS | 16:34.01 |
| kens | henrys, but then our WINdows users are out in the cold | 16:34.17 |
| | Most would have no ability to rebuild GS | 16:34.28 |
| henrys | kens: then they don't use compile inits | 16:34.43 |
| kens | The free users generally *DON'T* build GS | 16:34.59 |
| | So you are forcing them to download and install VS Express and rebuild GS with special options, just to get the ability to configure GS | 16:35.31 |
| | THat's a pretty big ask | 16:35.44 |
| | Better that we go back to shipping the default build without ROM file system | 16:36.08 |
| henrys | kens: 2 releases. | 16:36.38 |
| kens | I don't think that's a good idea.... | 16:36.53 |
| | People will always install the wrong one | 16:37.01 |
| henrys | kens: it doesn't make sense to say the resources are read only and configurable. | 16:37.17 |
| kens | THey are 'overrideable' | 16:37.40 |
| | THe ROM file system is a default if nothing else is provided, you can't write to the default, but you can override it | 16:38.02 |
| chrisl | henrys: having a COMPILE_INITS build ignore GS_LIB and -I would *seriously* piss off a *lot* of users (commercial and free) at this point | 16:39.24 |
| henrys | kens: then why do we have the other configuraton COMPILE_INITS = 0 at all? | 16:39.45 |
| kens | WHy do we have 3 ways to specify the override ? Convenience | 16:40.17 |
| chrisl | COMPILE_INITS=0 gives a *much* smaller executable | 16:40.25 |
| henrys | chrisl: alright give 'em the rope! | 16:41.36 |
| chrisl | henrys: frankly, this is a discussion that should have happened when COMPILE_INITS was introduced, not several years after the event | 16:41.51 |
| henrys | chrisl: I don't know if it was thought about, we obviously can't anticipate everything, rayjj was the primary driver wasn't he? | 16:45.03 |
| | chrisl: anyway I'll add it to the agenda | 16:45.15 |
| | thanks for clarifying | 16:45.28 |
| chrisl | henrys: I don't know, but given that we've told a *lot* of customers and free users to use -I and/or GS_LIB for doing install specific customisations, I think it would be a really bad idea to change the behaviour | 16:46.36 |
| | henrys: in fact, our own installer on Windows uses it...... | 16:47.05 |
| kens | I agree, there's a lot of 'knowlege' out there that relies on GS_LIB or -I working (especially -I) | 16:47.15 |
| henrys | hi fredross-perry | 16:51.10 |
| fredross-perry | hi henry | 16:51.19 |
| | writing you an email right now | 16:51.27 |
| henrys | chrisl: one thing I like about mac apps being a directory with their resources underneath, easy to install multiple apps | 16:53.52 |
| kens | Its just as easy with an execyutable with a ROM file system. Easier if anything | 16:54.46 |
| chrisl | henrys: FWIW, having a COMPILE_INITS=1 build ignore search paths other than %rom% would actually make the situation worse..... | 16:55.43 |
| henrys | fredross-perry: oh I thought this was the usual xps writing slowness, we have new slowness, ;-( | 16:56.19 |
| fredross-perry | henrys: probably not new, but just an issue of when it happens. | 16:57.16 |
| henrys | chrisl: my assumption was it would be illegal to use -I, GS_LIB etc. with a rom file system and you've made clear that won't fly because of current usage patterns. Right? | 16:58.36 |
| chrisl | henrys: yes, exactly. Plus, forcing anyone wanting to use, for example, a custom Fontmap or cidfmap for each installation to use a COMPILE_INITS=0 build would still leave us relying on GS_LIB and/or -I | 17:00.04 |
| kens | We've allowed it for ages, and there are lots of SO answers, blogs, articles, HOWTOs etc which assume this works when giving a recipe to solve a problem | 17:00.05 |
| kens | thinks; the genie has left the bottle..... | 17:01.22 |
| henrys | yes I think if we did what I'm suggesting the "default" download would be compile_inits = 0 and most folks would use that. | 17:03.19 |
| | anyway it's on the agenda | 17:03.30 |
| kens | We used to have the default being COMPILE_INITS=0 and we changed it. | 17:03.55 |
| | And it still doesn't get us past the problem, as chrisl pointed out. | 17:04.07 |
| chrisl | henrys: but then the problem of GS_LIB conflicting between "normal" installs and customer uses would still exist (and be potentially much worse) | 17:04.26 |
| kens | If I install GS alongside an existing installation, then GS_LIB will point to the new version. When I run the old version it will read the new init files and throw an error | 17:04.44 |
| | I used to get this all the time until I defined GS_LIB= | 17:05.11 |
| chrisl | That's less of an issue now that we use the registry key which is tied to the specific GS version number, but still....... | 17:06.02 |
| kens | I htink GS_LIB overrides the registry key as well. | 17:06.32 |
| chrisl | It does, yes | 17:06.40 |
| kens | So if you have GS_LIB defined, it had better be correct | 17:06.43 |
| chrisl | The priority order is -I, GS_LIB environment, GS_LIB registry, default | 17:07.19 |
| kens | And for non-Windows builds the same but without the registry option I assume | 17:08.07 |
| chrisl | Yes | 17:08.15 |
| henrys | a bit confused why GS_LIB isn't version specific. That's the first thing gs_init.ps checks. | 17:08.33 |
| kens | Tha'ts more or less what Chris was suggesting the other day, a vendor-specific environment variable | 17:09.27 |
| | So that the regular GS_LIB wouldn't be read and wouldn't interfere with a custom version. | 17:09.46 |
| chrisl | I think henrys meant purely based on the GS version number - that still wouldn't solve the interaction problem | 17:10.37 |
| kens | We still want our customers to be able to build a GS version which won't pick up any of the information from a regular installation | 17:10.40 |
| henrys | chrisl: yes that's true. | 17:11.07 |
| kens | So the environment variable needs to be a compile time option (which I think Ray suggested it is) and on WIndows the registry key needs to be able to be defined | 17:11.23 |
| | WHile it would be 'nice' to have GS_LIB be version specific, it doesn't get us past the problem of a customer build picking up information form an ordinary Ghostscritp installation, we need to be able to insualte against that | 17:12.13 |
| | Its also somethign we probably need to make more obvious in the documentation as a potential problem | 17:12.55 |
| chrisl | kens: the keys, I think, are specific as macros which you can define for yourself - I was suggesting it would be good to have a well defined way of doing so | 17:13.12 |
| | s/specific/specified | 17:13.27 |
| kens | As long as we *can* have this all be defined by the user at compile time, then we are in good shape. The main thing is to communicate ot people building GS that they need to do this (and make their own keys version-specific to avoid their installations colliding too) | 17:14.19 |
| | Any way, I'm off now, night all | 17:15.00 |
| chrisl | It probably means the installer needs some tweaks.... | 17:15.11 |
| avih | dinamic: do you know how to enumerate object properties? | 20:17.25 |
| | arrays have getlength and getindex, bow how to you list all object properties? | 20:18.03 |
| | (and names) | 20:18.09 |
| | or rather, enumerate property names. and such api maybe should also support hasOwnProperty related cases | 20:22.45 |
| | Forward 1 day (to 2014/10/30)>>> | |
IRC Logs