| <<<Back 1 day (to 2012/05/26) | 2012/05/27 |
Kilobajt | Hi! I just wanted to say that I figured out why PDF/A-2B files don't validate in Preflight | 00:16.11 |
| problem is with /CIDSet parameter | 00:16.55 |
| if you set it to some unknown reference for example from /CIDSet 15 0 R to /CIDSET 99 0 R file will validate successfully | 00:17.46 |
| also if you remove CIDSet completely file validates ok | 00:18.13 |
| please forward this info to "kens" | 00:21.22 |
| preflight was complaining because /CIDSet is incomplete (it has only used characters in file, not all of them) - so if you remove it completely (not required to have a valid file) you get a valid PDF/A-2B file. | 00:27.16 |
| code fix (gdevpdtd.c, line 690): pprintld1(s, "/CIDSet %ld 0 R\n", cidset_id); | 00:35.46 |
| change to: | 00:35.49 |
| if(pdev->PDFA != 2) | 00:35.54 |
| { | 00:35.54 |
| pprintld1(s, "/CIDSet %ld 0 R\n", cidset_id); | 00:35.54 |
| } | 00:35.54 |
| it's a hack, but it works :) | 00:36.04 |
sebras | Robin_Watts tor8: I think there are a few silly patches on sebras/master for you to review. | 12:19.11 |
Robin_Watts | sebras: Thanks. Will look tomorrow. | 23:13.11 |
sebras | Robin_Watts tor8: tor8 asked me to rebase on top of origin/master, which I did. locally. then push failed becuase I forgot -f... but now it's done! | 23:31.37 |
saper | why was -f necessary (just curious)? | 23:34.35 |
Robin_Watts | When you push to git, you send changes from your branch to a branch on a remote repo, right? | 23:41.18 |
| If those changes are all 'fast-forwards' (i.e. are new commits on the end of the existing branch) then you aren't losing any data - you're just adding new states to the git graph. | 23:41.53 |
| If however, you've made changes that aren't all fast forwards (such as may be the case if you've rebased the branch) then when you push you are effectively unlinking states from the graph. | 23:42.56 |
| Git doesn't like that (as it can lead to lost commits), so it makes you use the -f option (to force the push). | 23:43.27 |
sebras | saper: or a bit shorter, if you add new commits to an existing branch -f is not needed. if you are replacing commits on a branch or you are changing the branch point you do need -f. though Robin is perfectly correct in what he writes. :) | 23:44.56 |
| saper: and Robin/tor8 asked me to rebase my changes to origin/master since they want to have a simple job of merging (i.e. the let me do the job of resolving any conflicts). | 23:45.58 |
saper | ah, so your commit shared a parent with some other commit(s), right? | 23:45.59 |
sebras | saper: ASCII-art says more than a thousand words, or so I hope... | 23:49.00 |
| Before rebase: | 23:49.01 |
| A---B---C sebras/master | 23:49.01 |
| / | 23:49.01 |
| D---E---F---G origin/master | 23:49.01 |
| After rebase: | 23:49.03 |
| A'--B'--C' sebras/master | 23:49.05 |
| / | 23:49.08 |
| D---E---F---G origin/master | 23:49.10 |
| So basically I changed the branch point of | 23:49.13 |
| my own branch. Thus I need -f. | 23:49.15 |
| I'm shamelessly adapting man git-rebase for you here. ;) | 23:49.24 |
saper | ah, so the problem is, A, B, C where already known to your target repo and you are suddenly telling git "forget C as sebras/master, use C'" | 23:54.47 |
sebras | saper: exactly. | 23:55.04 |
saper | I am working a lot with gerrit (code review tool for git), and we have there is every submission for review is put as "ref/changes/XXXX/01" until merged | 23:55.56 |
| if I update the patch, it will be "refs/changes/XXXX/02" etc. so there is no "moving pointer" | 23:56.30 |
sebras | saper: true. but git permits more things than gerrit. :) | 23:57.05 |
saper | of course, gerrit is in some ways exteremely limiting I find | 23:57.47 |
sebras | saper: though it is a new review tool. | 23:58.09 |
| Forward 1 day (to 2012/05/28)>>> | |