| | <<<Back 1 day (to 2013/05/01) | 2013/05/02 |
| kens | chrisl did you see teh ft-devel email from Wener about CFF ? | 06:58.34 |
| chrisl | kens: no, I'll look now | 07:01.13 |
| | Hmm, very cool - shame it doesn't include type 1! | 07:02.51 |
| kens | True, but then as they say most fonts are either CFF or TT these days. And we canalwsays convert to CFF :-) | 07:03.21 |
| chrisl | gotta go drive a parent around...... | 08:06.28 |
| natronite | Good morning | 08:36.51 |
| | any mupdf developers around? | 08:37.03 |
| | hello | 08:54.48 |
| ghostbot | hola, natronite | 08:54.48 |
| tor8 | natronite: yes. | 08:55.09 |
| natronite | :D | 08:55.14 |
| tor8 | but we're sometimes a bit laggy :) | 08:55.33 |
| natronite | when rendering files with some images I get errors and warnings the first time I render it. If I render it a second time all is well and the page displays correct | 08:56.09 |
| | what could that be? | 08:56.13 |
| | Warnings and errors like "error: cannot find xobject resource: 'Im21'" | 08:56.25 |
| | "warning: cannot draw text since font and size not set" | 08:56.33 |
| | 'error: cannot find extgstate resource 'GS1'' | 08:56.45 |
| tor8 | the second render time may reuse a cached display list from the first render | 08:56.56 |
| | then you won't see the errors and warnings from the interpreter more than once | 08:57.16 |
| | if the renders are not the same (i.e. you see errors and broken rendering the first time, and no errors and correct rendering the second) then I have no idea | 08:58.05 |
| | are you using mudraw, the windows viewer or the android app? or writing your own? | 08:58.30 |
| natronite | I'm writing my own android app | 09:00.00 |
| | I have adapted the C code from the demo | 09:00.16 |
| tor8 | can you reproduce the problems with the stock code? | 09:00.41 |
| natronite | to read the file into memory from a zip file | 09:00.41 |
| | I can see if the file can be read from the mupdf app | 09:01.10 |
| | without the errors | 09:01.15 |
| tor8 | if you adapt mudraw to use a memory stream, does that also have problems? | 09:03.10 |
| natronite | I will see if I can find out. Let me get back to you guys. | 09:07.12 |
| Robin_Watts | tor8: Morning | 09:47.50 |
| tor8 | hey robin | 09:47.58 |
| Robin_Watts | In yesterdays fonty stuff... | 09:48.05 |
| | One of the 3 font names was spotted as being a fallback font, right? (ArialMT) | 09:48.31 |
| | but the other two werent (Arial-BoldMT and Arial-BoldItalicMT) | 09:48.49 |
| tor8 | that one was spotted as being a "builtin" core-14 font | 09:49.01 |
| | the others weren't | 09:49.05 |
| Robin_Watts | right. | 09:49.05 |
| tor8 | so it didn't get flagged as a substitute font | 09:49.18 |
| Robin_Watts | Is that anything we can do anything about? | 09:49.19 |
| tor8 | cid-fonts shouldn't ever get treated as builtin fonts, only simple fonts should get that | 09:49.42 |
| | so that's the first patch | 09:49.47 |
| Robin_Watts | Right. I follow that. | 09:49.54 |
| tor8 | with that patch, all three are treated equivalently | 09:49.57 |
| Robin_Watts | I was wondering if this was a different problem. | 09:50.07 |
| | Does Freetype know how to italicise or bolden fonts? | 09:50.11 |
| tor8 | so with NODROIDFONT they all get garbage encodings | 09:50.12 |
| kens | artifical italic isn't hard. Artifical bold is harder | 09:50.38 |
| Robin_Watts | should/could we spot Arial-BoldMT (for example) as being a boldened version of Arial? | 09:50.47 |
| tor8 | we have artificial italic and boldening using freetype | 09:50.53 |
| | using the same values as XPS requires for its artificial bold/italic | 09:51.09 |
| kens | Robin_Watts : the way to get 'better' substitution is to use a Multiple Master font | 09:51.36 |
| tor8 | Robin_Watts: I believe the detection didn't work because of the basename being "Arial-BoldMT,Bold" with the ,Bold on the end | 09:51.37 |
| | the second patch uses the ToUnicode in the rare cases of "substitute font && identity encoding" | 09:52.19 |
| Robin_Watts | tor8: yeah, I was just wondering if we should have a bug open for better spotting of font styles from names. | 09:52.45 |
| tor8 | Robin_Watts: look at pdf_load_system_font | 09:53.54 |
| | we correctly spot Arial-BoldMT as being bold, no problem | 09:54.33 |
| | both by looking at the basename (strstr("Bold")) and the fontdescriptor flags | 09:54.52 |
| | in pdf_load_substitute_font we set font->ft_bold to let freetype know to artificially bolden it | 09:55.57 |
| | if (font->ft_bold) | 09:56.25 |
| | { | 09:56.26 |
| | FT_Outline_Embolden(&face->glyph->outline, strength * 64); | 09:56.27 |
| | FT_Outline_Translate(&face->glyph->outline, -strength * 32, -strength * 32); | 09:56.28 |
| | } | 09:56.29 |
| | where strength is based on the font size | 09:56.42 |
| Robin_Watts | ok | 10:00.47 |
| tor8 | with NODROIDFONT set, we get more accurate styles (using all the base 14 fonts) but lacking glyph coverage | 10:01.48 |
| Robin_Watts | Ah. In base_font_names, we have Arial-BoldMT and Arial,Bold, but not Arial-BoldMT,Bold. | 10:04.02 |
| | I was wondering if we should chop the ,Bold off the end and try to rematch the string or something. | 10:04.51 |
| | tor8: 2 commits on robin svgwrite. The first one is good to go, the second is the work in progress. | 10:05.55 |
| | For pdfwrite/xpswrite/svgwrite I had to change mudraw a bit to have a better way of spotting output suffixes. | 10:06.36 |
| | cos asking for -o input.pdf.svg input.pdf would make it think that it wanted PDF output. | 10:07.23 |
| tor8 | Robin_Watts: pdfref 1.4 page 815 has the table from which we get the base_font_names | 10:07.24 |
| | pdfref 1.3 has no such table | 10:07.54 |
| | pdfref 1.5 has a much slimmed version of the table | 10:08.05 |
| Robin_Watts | 1.7 has a slim table on page 1109 | 10:08.23 |
| tor8 | yeah. that's the same as introduced in 1.5 | 10:09.13 |
| | so the 1.4 table may be an abberration | 10:09.39 |
| | "Also, Acrobat 4.0 and earlier viewers incorrectly allow substitution fonts, such as TimesNewRoman and ArialMT, to be specified without FirstChar, LastChar, Widths, and FontDescriptor entries." suggests that ArialMT should be a substitute font, not a standard (builtin) font | 10:10.29 |
| | we could try slimming the base_font_file table and running bmpcmp to see if we break anything | 10:10.57 |
| Robin_Watts | Or we could wait for a problem to be reported :) | 10:11.16 |
| | Fonts have a way of just sapping my will to live. | 10:11.24 |
| | I got prodded again by customer 530 about the mesh code last night, so I am going to grab your commit and do some timings today. | 10:11.50 |
| tor8 | do/while(change)? | 10:12.28 |
| | is that just looking for the last suffix? | 10:12.55 |
| Robin_Watts | it is. | 10:13.29 |
| tor8 | suffix = strrchr(output, '.'); | 10:13.31 |
| Robin_Watts | tor8: OK,but we'd still need a loop. | 10:14.27 |
| | -o out.pdf.png.2 | 10:14.38 |
| tor8 | why would you have a broken filename like that? | 10:15.12 |
| Robin_Watts | tor8: because, people are awkward. | 10:15.54 |
| | We want to find the last suffix that matches one of our types. | 10:16.12 |
| tor8 | struct { char *suffix; int format; } = { { ".ppm", OUT_PPM }, ... | 10:16.18 |
| Robin_Watts | data driven - yeah, could do. | 10:16.44 |
| | tor8: Updated patch online. | 10:36.04 |
| | Ah! Marti has just merged the commits. excellent. | 10:40.38 |
| tor8 | Robin_Watts: you can use the nelem() macro to avoid having a sentinel entry in the table | 10:51.52 |
| | for (i = 0; i < nelem(suffix_table); i++) | 10:52.02 |
| Robin_Watts | tor8: ok. | 10:52.25 |
| | also, I can put the colorspace into the table. | 10:52.35 |
| tor8 | it's not something I care about strongly, just wanted to let you know we do have that macro in our header files | 10:52.55 |
| | then I'd call it format_table :) | 10:53.16 |
| Robin_Watts | yeah. | 10:59.52 |
| | actually, I prefer it with the colorspace out of the table. | 11:04.05 |
| tor8 | Robin_Watts: could you take a look at tor/rtl, the WIP linked list patch | 11:33.05 |
| | there's a section there with the line merging that could do with some help | 11:33.15 |
| natronite | if I render the pdf to a file with mudraw it works perfeclty | 11:39.07 |
| | but from my code the first time it has errors and warning | 12:07.22 |
| | and after reloading it into memory it does not have those errors and warnings anymore. and it displays correctly | 12:07.53 |
| tor8 | have you made 100% certain that your memory buffer is identical before and after reloading? | 12:11.20 |
| natronite | I thought about verifying that. What's the best method to do so? | 12:13.06 |
| tor8 | memcmp? | 12:13.13 |
| natronite | That would work if I still had access to the first memory part :p the reloading happens because the cached memory gets reused for another document | 12:14.55 |
| tor8 | you could stow away a copy of it :) | 12:15.12 |
| | alternatively, make an md5 digest of it and log that | 12:15.25 |
| natronite | well. I'll find a way :p thanks and tty in a couple of minutes | 12:15.50 |
| | so | 12:28.07 |
| | so far the pages I compared have the same memory backing them up | 12:28.25 |
| Robin_Watts | tor8: will look soon. | 12:33.42 |
| mcs | Hi, i need to ask one question regarding bounding box . I will be thankful if someone can share their opinion on the issue | 12:35.21 |
| | I am getting a bounding-box of the text. The dimension looks OK. | 12:38.37 |
| | However, the box is displaced in both x and y, towards down and right | 12:39.01 |
| | and this displacement is not linear, as you move to the right and down, it increases slightly exponentially | 12:39.30 |
| | so for example, if you get the bbox of the upper top paragraph, 3 lines are missed from the top (I am rendering the bbox) | 12:40.18 |
| | But if you get the bbox of a lower paragraph, 5 lines are missing from top, for eg | 12:40.53 |
| | same for right displacement | 12:41.01 |
| | so as you move to the right, the displacement increases | 12:41.18 |
| | also, its different for different resolutions | 12:41.31 |
| | on a phone of resolution 960 x 540, its less | 12:41.55 |
| | but for a phone for 800 x 480 resolution, its more | 12:42.11 |
| | so its resolution dependent | 12:42.18 |
| | any ideas? why is the bounding box returned from the library displaced? | 12:42.41 |
| tor8 | mcs: which bbox from which library? | 12:42.51 |
| mcs | MuPDF | 12:43.13 |
| | bbox of the text you double tap on | 12:43.26 |
| tor8 | bbox device? display list bboxes? text bbox? | 12:43.29 |
| | the text bboxes depend on the transform you pass when running the page through the text device | 12:43.52 |
| mcs | hmm | 12:44.21 |
| tor8 | it will be resolution dependent, if the transform you pass is the same as you use to render the resolution dependent bitmap | 12:44.41 |
| | if you pass fz_identity the bboxes will be resolution independent. if you pass the same transform as for rendering, the bboxes will be in screen coordinates. | 12:45.19 |
| mcs | where are we passing this transform? | 12:45.51 |
| tor8 | fz_run_* | 12:46.06 |
| mcs | thanks, let me have a look | 12:46.57 |
| natronite | so far the pages I compared have the same memory backing them up | 12:48.29 |
| tor8 | natronite: can you reproduce the error in a stripped down sample code that does not involve java? | 12:49.53 |
| | I can't think of anything other than corrupted input data that would cause those kinds of errors | 12:50.16 |
| | I'm afraid you'll have to start thinking about how you can use valgrind | 12:50.44 |
| natronite | hmm.. stripped down sample code that renders to a png for instance? | 12:51.03 |
| | I couldn't reproduce it with mudraw | 12:51.16 |
| | valgrind? | 12:51.19 |
| tor8 | natronite: yes, that would be perfect (a standalone sample that renders to png) | 12:51.50 |
| | valgrind is a memory debugger that catches all sorts of wonderful errors. linux only as far as I know. | 12:52.09 |
| | it catches uninitialized memory accesses and accessing freed memory etc etc | 12:52.27 |
| natronite | ok. sometimes only a couple of images are disolayed instead of all. | 12:53.20 |
| tor8 | mupdf being non-deterministic suggests some serious memory breakage | 12:53.50 |
| | or file access problems | 12:53.58 |
| natronite | ok. I'll try to adapt mudraw to see if we can create pngs | 12:54.26 |
| | with our code parts | 12:55.05 |
| tor8 | natronite: if you have your code somewhere I could take a brief look and see if I spot anything obvious | 12:55.28 |
| natronite | i do have the c code as it is. But it's not accessible online. Can I mail it to you? | 12:57.44 |
| tor8 | mail is fine | 12:59.58 |
| natronite | Could it be that we access the zip file from C and Java at times? | 13:03.51 |
| tor8 | if it's in Java memory and the garbage collector moves it, you're in trouble | 13:04.49 |
| natronite | we open the file from within c with minizip | 13:07.20 |
| tor8 | kens: I just assigned a gxps/pdfwrite bug to you | 13:07.24 |
| natronite | what is your email? | 13:07.27 |
| kens | tor8 the 'transparency' one ? | 13:07.38 |
| tor8 | kens: another one looks like it may be up your alley as well -- 693363 | 13:07.42 |
| | kens: the incorrect unicode one | 13:08.00 |
| | natronite: tor dot andersson at artifex dot com | 13:08.10 |
| kens | tor8 well I will look at it | 13:09.05 |
| natronite | ok. sent | 13:16.58 |
| kens | tor8 I suspect the ToUnicode CMap is a 'too bad' | 13:17.55 |
| tor8 | kens: quite possibly. the xps interpreter has access to the unicode text of the original strings, but that's not something the graphics library or pdf format can express in any form other than ToUnicode, which isn't exactly equivalent | 13:20.02 |
| kens | We do use information from the PostScript interpreter to construct ToUnicode CMaps (which is what I assume he's talking about here). Its possible we might do something as an enhancement. But as I keep telling people, if it looks the same, then its not a bug.... | 13:21.10 |
| tor8 | the original xps file has <Glyphs ... Indices="...." UnicodeString="Black RGB"> | 13:22.03 |
| | only the indices are used in gxps, the UnicodeString is tossed | 13:22.14 |
| | so unless the file has a decent font which can be used to construct a ToUnicode, we'll have to do some serious rearchitecting... | 13:22.52 |
| | we could possibly try to collect all the Indices and UnicodeString values for a given font and try to reverse engineer a ToUnicode from that | 13:23.18 |
| | but then we need a way to pass that all the way through to pdfwrite | 13:23.42 |
| kens | yes, I#'d have to look at how we deal with this in PS | 13:25.04 |
| tor8 | henrys: Robin_Watts: to go back to the svgwrite discussion of yesterday, XPS has all state explicitly on all elements if you look at what microsoft puts out. no state tracking optimisations by nesting canvases etc. | 13:25.18 |
| Robin_Watts | tor8: ok. I have something that seems to work, so we can tweak it later as required. | 13:26.35 |
| | Let me look at this rtl stuff... what was the particular issue. | 13:26.53 |
| tor8 | Robin_Watts: you have what working? | 13:27.12 |
| Robin_Watts | svgwrite. | 13:27.25 |
| tor8 | Robin_Watts: me not understanding your logic when merging two lines | 13:27.26 |
| | ah right! | 13:27.29 |
| | (goldfish memory...) | 13:27.37 |
| Robin_Watts | when your goldfish gets alzheimers you'll have caught up with me. | 13:27.58 |
| tor8 | we should probably do a big cleanup pass on the text extraction layer now that you're happy with how it works | 13:29.03 |
| Robin_Watts | tor8: I'm not *happy* :) | 13:29.15 |
| tor8 | I'm rather unhappy with how messy the code is... and the data structure basics are sound but working with them is a PITA | 13:29.44 |
| Robin_Watts | actually, I'm happy I haven't had to look at it for a while. does that count? | 13:29.44 |
| tor8 | :) | 13:30.07 |
| Robin_Watts | So, what file, what line does the confusion start ? | 13:30.30 |
| | chrisl: Are you pulling in the new shiny adobe/google fettled freetype ? | 13:31.23 |
| tor8 | fitz/text_paragraph.c:1507, the #if 0 block | 13:31.46 |
| Robin_Watts | http://git.ghostscript.com/?p=user/tor/mupdf.git;a=blame;f=fitz/text_paragraph.c;hb=ec343f37a181f4ffe823cafa5a194040ae498767 | 13:32.08 |
| | 1390 ? | 13:32.20 |
| tor8 | eh, yes. 1390. | 13:32.45 |
| | can't even read the status line properly :) | 13:32.53 |
| Robin_Watts | OK. Suppose we have text laid out in 2 columns. Let me try for an example. | 13:33.00 |
| | This is the first This is the second | 13:33.40 |
| | column of text column of text and | 13:33.41 |
| | and it carries it's shorter. | 13:33.43 |
| | on like this. | 13:33.45 |
| tor8 | right. | 13:33.50 |
| Robin_Watts | We'll grab those as 4 lines. | 13:34.23 |
| | all 4 will end up with the same region mask, I believe. | 13:34.39 |
| | This code is to do with recognising that the "on like this" carries on from the first column. | 13:35.40 |
| tor8 | hm, wouldn't those two columns end up in two separate blocks? | 13:35.57 |
| Robin_Watts | Not currently. | 13:36.18 |
| | Cos we have no code in there to distinguish between columns in a table, and columns of text. | 13:36.38 |
| | This also copes with pulling multiple lines together in a single column layout. So paragraphs are collated into lines. | 13:37.50 |
| | The fact that paragraphs are collated into lines matters for the indent spotting. | 13:39.14 |
| tor8 | right. so after step 7 we should end up with: | 13:40.25 |
| | "This is the first This is the second" | 13:40.33 |
| | ... | 13:40.36 |
| | "and it carries on like this. it's shorter." | 13:40.50 |
| | ? | 13:40.51 |
| Robin_Watts | Yes. | 13:40.59 |
| | although I'd probably have written it more like: | 13:41.11 |
| | 1"This is the first" 2"This is the second" | 13:41.23 |
| | ... | 13:41.24 |
| | 1"and it carried on like this" 2"it's shorter" | 13:41.39 |
| | or maybe even: | 13:42.16 |
| | 1"and it carries" 1"on like this" 2"it's shorter" | 13:42.33 |
| | depending on how much notation we want to use. | 13:42.43 |
| tor8 | right. | 13:42.50 |
| | where the 1"..." etc are the spans | 13:43.05 |
| Robin_Watts | the column number/spans, yes. | 13:43.23 |
| | I am absolutely open to ideas for improving this :) | 13:44.07 |
| tor8 | consider this: | 13:44.14 |
| | FeeHelloGoodbye, | 13:44.15 |
| | Fieworldcruel | 13:44.15 |
| | Foeworld! | 13:44.16 |
| | Foo | 13:44.17 |
| | argh. tabs didn't paste properly. but one word per column and a gap in "Foe world" | 13:44.35 |
| Robin_Watts | I follow | 13:44.41 |
| tor8 | three columns, of different height | 13:44.55 |
| | that one should work as expected, going by the comments of "only merge lines if the second line only uses 1 of the columns" | 13:45.39 |
| | should *not* work as expected, I mean | 13:46.03 |
| Robin_Watts | Foo will be pulled into Foe. | 13:46.08 |
| | but that's all. | 13:46.21 |
| tor8 | and if there wasen't a Foo line | 13:46.35 |
| | so this isn't actually a vital step in multi-column cases | 13:47.01 |
| Robin_Watts | I'm trying to think why I imposed the "only pull stuff in if only 1 column is in use" rule. | 13:47.01 |
| | possibly we should drop that rule and see what happens. | 13:48.09 |
| tor8 | only merge lines if they are both single column, and same column? | 13:55.28 |
| Robin_Watts | no, merge lines if they share the same region mask. | 13:55.59 |
| | so we'd get 1"Fee" 1"Fie" 1"Fo" 1"Fum" 2"Hello" 2"World" 3"Goodbye" 3"Cruel" 3"World!" | 13:56.39 |
| tor8 | that'd break tables though! | 13:56.54 |
| Robin_Watts | Would it? | 13:57.02 |
| | We only merge within blocks. | 13:57.20 |
| tor8 | well, if you merge all columns into one line, tables wouldn't be tables anymore... | 13:57.21 |
| | and the comment for Step 5 seems to indicate that producers don't write columns of text such that we'd get columns that look like tables | 13:57.59 |
| | a table is one block, with a line per row, and a span per cell... or am I completely off track? | 13:58.32 |
| Robin_Watts | it depends whether we detect the gaps between lines in a table as being a new block or not. | 13:58.59 |
| tor8 | random thought: have separate text representations for the three use cases | 13:59.45 |
| Robin_Watts | the 3 use cases being? | 14:00.03 |
| tor8 | 1) collection by the text device | 14:00.07 |
| | 2) post process to sort into columns and paragraphs | 14:00.22 |
| | 2) post process for visual to logical RTL ordering | 14:00.31 |
| | 3) html output and reflow | 14:00.47 |
| | 4) flat text access for search and copy/paste | 14:00.53 |
| | make that 4 use cases | 14:00.57 |
| Robin_Watts | or 5 ? | 14:01.08 |
| tor8 | 2) post processing to normalize unicode | 14:01.25 |
| | or 6 :) | 14:01.30 |
| Robin_Watts | I'm not entirely averse to the idea of changing representation. | 14:01.43 |
| | I have the vague feeling it would be nice for the steps to be independent of one another though. | 14:02.01 |
| tor8 | I was thinking 1, 2/3, and 4 would probably be best served by separate representations | 14:02.09 |
| Robin_Watts | possibly. | 14:02.23 |
| tor8 | search is hugely inefficient now, being able to random access (or just iterate efficiently) the unicode text and bboxes would probably speed it up a lt | 14:02.47 |
| | lot* | 14:02.49 |
| Robin_Watts | Certainly, at the collection stage, we don't do an exhaustive search for the best place to put lines in the ordering. | 14:03.10 |
| | (when we strain_soup). | 14:03.17 |
| | s/lines/spans/. | 14:03.30 |
| | a better data structure could help us there. | 14:03.49 |
| tor8 | strain_soup is the rudimentary collection into blocks/lines that we had from before | 14:04.03 |
| Robin_Watts | tor8: yes. | 14:04.21 |
| tor8 | and paragraph analysis breaks that into more reasonable units by doing whole page analysis | 14:04.34 |
| | looking at line heights and region masks for columns | 14:04.44 |
| | Robin_Watts: okay, butchered version on tor/rtl now. could you give that a spin and see if it acts reasonably? I changed it to only merge lines if there is only one span per line and they're in the same column | 14:15.56 |
| Robin_Watts | tor8: OK. I'll do an android build in a mo, then we can reflow various docs through it. | 14:16.49 |
| | just answering this support email about leaks. I really can't see the evidence for any leaks. | 14:17.12 |
| tor8 | natronite: okay, looking through your file now | 14:21.00 |
| Robin_Watts | tor8: oh, balls. | 14:52.23 |
| | I can't do an android build trivially, cos you've changed the data structures :( | 14:52.40 |
| tor8 | ah. | 14:53.07 |
| | want me to fix that? | 14:53.18 |
| Robin_Watts | let me see if I can cure it easily. | 14:53.44 |
| tor8 | shouldn't be more than fixing a few for loops for the span iteration | 14:54.06 |
| | - for (span_num = 0; span_num < line->len; span_num++) | 14:55.13 |
| | + for (span = line->first_span; span; span = span->next) | 14:55.14 |
| Robin_Watts | We don't have a line->len any more... | 14:56.09 |
| tor8 | right. at the java marshaling further down it breaks... | 14:56.29 |
| Robin_Watts | fixed. | 14:57.50 |
| | windows builds are unhappy about the lack of stdint.h | 14:58.14 |
| | required by ucdn.c | 14:58.22 |
| tor8 | hmm. | 14:58.48 |
| | what gives uint32_t on windows? | 14:59.08 |
| Robin_Watts | windows Release build that was. Trying a debug build now. | 14:59.13 |
| henrys | tor8:yes that's one thing that makes xps hellishly large and a terrible choice for a printer language. | 14:59.19 |
| tor8 | morning henrys | 14:59.33 |
| Robin_Watts | yeah, debug build fails too. | 14:59.33 |
| henrys | tor8:but I guess we should just go along with it. | 15:00.55 |
| tor8 | henrys: when in Rome... | 15:01.27 |
| henrys | tor8:yup | 15:01.34 |
| | Robin_Watts: yea SOA is very good, did you see the following finale yet? | 15:04.10 |
| Robin_Watts | henrys: yeah. | 15:04.17 |
| | vaguely disappointed by the following finale. | 15:04.44 |
| henrys | hard to imagine next season without the villain | 15:05.02 |
| Robin_Watts | for reasons I won't go into here. | 15:05.09 |
| | http://ghostscript.com/~robin/MuPDF-rtl.apk | 15:10.02 |
| | tor8: ^ | 15:10.07 |
| tor8 | entering reflow mode crashes the activity | 15:19.41 |
| Robin_Watts | tor8: urgh. | 15:20.19 |
| | I promised 530 I'd look at your mesh stuff for them today - can we come back to the rtl stuff tomorrow? | 15:21.14 |
| tor8 | Robin_Watts: sure. I'm about done for the day. livingroom's getting too hot and stuffy. summer's almost here... | 15:23.04 |
| Robin_Watts | tor8: In the mesh stuf... | 15:32.13 |
| | f | 15:32.15 |
| | In fz_paint_triangle... you do: float x0 = roundf(c0[0]) | 15:32.42 |
| | Why have x0 as a float then? | 15:34.05 |
| kens | henrys ping | 15:36.28 |
| henrys | kens:yes | 15:36.39 |
| tor8 | Robin_Watts: avoiding converting float -> int -> float | 15:36.52 |
| kens | the two patches on my repository each have one regression | 15:37.01 |
| Robin_Watts | Why convert it back to a float? | 15:37.02 |
| | Why not pass it into paint_scan as an int ? | 15:37.18 |
| kens | the high level patterns one has regressin in 14-09.bin | 15:37.35 |
| | the 'Intellifont as type 3' one has a regression in c706.bin | 15:37.50 |
| | WHat do you want me to do ? COmmit and open bugs? | 15:38.07 |
| Robin_Watts | tor8: In paint_scan you always want it as an int (except for where you / (fx1 - fx0), and that will be converted to a float anyway due to the numerator being floaty) | 15:38.51 |
| henrys | I think commit and open bugs | 15:39.09 |
| kens | OK no problem. | 15:39.15 |
| | I'll do that tomorrow when I hopefully won't make mistakes :-) | 15:39.34 |
| tor8 | Robin_Watts: I was trying out rounding it later as well | 15:42.03 |
| Robin_Watts | right. | 15:42.12 |
| tor8 | feel free to integerize and fixedpointify the lot | 15:42.13 |
| | load_edge could be optimized by using deltas and stepping instead of computing the lerped values directly each scanline | 15:43.05 |
| Robin_Watts | tor8: yeah. | 15:43.13 |
| | I'm still getting white pixels here :( | 15:43.25 |
| | oh. building release, testing debug. d'oh. | 15:43.41 |
| tor8 | there are one or two still in mesh3.pdf but it's much better | 15:44.01 |
| | compare rotating 15 degrees with a/s | 15:44.07 |
| Robin_Watts | yes, testing the right one makes it look a lot better :) | 15:44.53 |
| | Why do you use ceilf ? | 15:45.08 |
| | (and roundf for that matter) | 15:45.15 |
| | floorf/roundf/ceilf are much slower than just using adds and casts, cos they test for over/underflow etc. | 15:45.57 |
| | I don't think we care about over/underflow here. | 15:46.06 |
| | and we are guaranteed (I think) that all our values are +ve. | 15:46.18 |
| | so removing the roundf is easy. | 15:46.42 |
| | Why did you pick ceilf? Could you not equally have picked roundf, or floorf there? | 15:47.05 |
| tor8 | Robin_Watts: simplicity | 15:47.16 |
| | ceilf for rounding upwards so we guaranteed get one scan line | 15:47.45 |
| | +1 and rounding down works too | 15:47.54 |
| | and also so we start with the first scan line intersecting the triangle | 15:48.18 |
| | biab, need to go for dinner | 15:48.33 |
| Robin_Watts | tor8: but we round both start and end up. | 15:48.41 |
| henrys | wow a gaps bug odd | 16:33.12 |
| | gxps that is | 16:33.19 |
| kens | 2 in fact | 16:33.35 |
| henrys | I have mixed feeling about people using xps, good for us bad for humanity in general | 16:35.07 |
| kens | goodnight all | 16:38.07 |
| henrys | Robin_Watts: maybe I'll start justified - checking netflix | 16:39.59 |
| Robin_Watts | henrys: Did you watch Fringe ? | 16:40.27 |
| henrys | I have to start watching all these programs on netflix I can't remember what's going on with a week break between shows | 16:41.08 |
| | no I didn't like the first few fringes and stopped does it get better | 16:41.58 |
| | ? | 16:41.59 |
| Robin_Watts | Fringe was utterly fabulous. | 16:42.16 |
| | got better and better and better as time went on. | 16:42.23 |
| | And I'm sure I've recommended Supernatural too. | 16:42.50 |
| | Supernatural is king of the "This can't possibly be good, but it is" stakes. | 16:43.23 |
| | I guess I like both Supernatural and Fringe because they have such strong overarching storylines that that just advance a bit each week. | 16:44.15 |
| henrys | wonders if he can find open source font substitutes for PCL fonts amongst these new google web fonts. | 17:09.40 |
| | looks like raph is part/lead on this project | 17:10.26 |
| | tor8:have you looked at the google web fonts at all? | 17:19.20 |
| Robin_Watts | remembers to vote. | 18:05.20 |
| mvrhel_laptop | bbiaw | 19:00.58 |
| tor8 | henrys: a bit. the catalogue is huge these days, seems like they'll let pretty much any font in | 20:43.05 |
| Robin_Watts | tor8: Optimised mesh plotter in robin/master | 20:51.42 |
| tor8 | Robin_Watts: will look tomorrow | 21:09.14 |
| | Forward 1 day (to 2013/05/03)>>> | |
IRC Logs