IRC Logs

Log of #ghostscript at irc.freenode.net.

Search:
 <<<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 Preflight00: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 successfully00:17.46 
  also if you remove CIDSet completely file validates ok00: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/master23:49.01 
  After rebase:23:49.03 
  A'--B'--C' sebras/master23:49.05 
  /23:49.08 
  D---E---F---G origin/master23:49.10 
  So basically I changed the branch point of23: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 merged23: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 find23:57.47 
sebras saper: though it is a new review tool.23:58.09 
 Forward 1 day (to 2012/05/28)>>> 
ghostscript.com
Search: