Page rotation is not a view setting, it's part of the PDF data That's why this
is not not a bug. Behavior is also consistent with e.g. Preview. So your
expectation is wrong. It won't work properly for many reasons, the once I
detailed are already sufficient. Quite frankly, I think this "discussion" is a
good example showing why I don't want to discuss this any further.
Christiaan
On Jan 7, 2011, at 0:30, tcb wrote:
> Hi,
>
> I would like to support Thomas' point of view here- I also think this is a
> bug in Skim, in that it is not the behaviour I expect.
>
> I often generate pdf data, examine it in detail, then re-generate the pdf.
> This involves viewing the pdf with various zoom and rotation settings. On
> reloading the pdf, I then have to reapply the rotation settings, although the
> zoom settings are remembered. I expect that the view settings are maintained
> when the pdf is reloaded- it makes no sense to have to reapply them. It would
> not be a sensible option to change the rotation in the pdf just for this,
> since I might have to view it in many different ways before I have it right-
> this is properly the job of the pdf viewer to view the pdf as I choose. I
> don't really see an issue with changing the default to this behaviour- for
> someone who has not changed the default view settings, they will see no
> difference when they reload the pdf. It might be possible to make this a
> hidden preference- 'reloadWithCurrentViewSettings'. Of course, there would
> then be some small overhead for implementing this behaviour for all pages-
> but a dictionary with a rotation code for each page that the user has
> manually changed, otherwise use the default (this is surely an insignificant
> overhead).
>
>
> On Thu, Jan 6, 2011 at 11:14 AM, Christiaan Hofman <[email protected]> wrote:
>
> On Jan 6, 2011, at 2:18, Thomas Schneider wrote:
>
> > Christiaan:
> >
> >> No, the problem is that you won't accept my explanation
> >
> > No, I understood your explanation and it's not relevant. You didn't
> > explain why N numbers are needed when obviously 1 (with 4 values) will
> > clearly do to set the state of how the entire document is viewed.
> >
> >> I am not saying that the information is expensive. My point is that
> >> using this information is expensive.
> >
> > I agree that setting page rotations for every page would be expensive,
> > but that's not what I want so you are thinking about the wrong
> > parameter(s). It's could be a terminology problem but when I say
> > 'rotate' you apparently think about the PostScript rotate command,
> > which is not what I am talking about.
> >
> >> Moreover, this is NOT a bug. It's the way the program behaves.
> >
> > If the way a program behaved always defined what it should do then
> > there would never BE any bugs! As far as I can see this is a design
> > bug or (minor!!) oversight to an otherwise beautifuly built program.
> >
> >> For good reasons. It also does exactly what you ask it to do: reload
> >> the data from disk (page rotation is part of the PDF data).
> >
> > Yes, page rotation is part of the PDF data. That's not what I'm
> > talking about. The program does not do exactly what I ask it to do:
> > create a stable display at the current hand (!!!!) settings.
> >
> >> A bug report list is NOT a place for discussion.
> >
> > Take a look at the discussions about SeaMonkey under bugzilla. In
> > many cases, holding a discussion outside the bug report location is
> > awkward at best because they are disconnected.
> >
> >> Moreover, I've said before, I'm not going into lengthy and
> >> frustrating back-and-forths anymore, where I have to repeat
> >> arguments that are subsequently ignored, and the conclusion has
> >> already been drawn.
> >
> > Right. Please don't repeat your arguments again. Your arguments so
> > far have not been relevant to the issue at hand. You have not made a
> > logical case for needing N variables. That's why I'm asking for
> > others to discuss this with since you apparently are only thinking
> > about one of the three (at least) kinds of rotation and not about the
> > thing I'm concerned with.
> >
> > Tom
> >
>
> I don't need to make a case, I only stating a FACT. And another FACT is that
> there don't exist three types of rotations, there is only one: the rotation
> of each page. The fact that there are multiple ways to affect this one piece
> of data does not change this fact. If you want a reason for these FACTS, then
> try to argue with Adobe.
>
> Everybody is entitled to his own opinion, but not to his own facts.
>
> Christiaan
>
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment, and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl_______________________________________________
> Skim-app-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/skim-app-users
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Skim-app-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/skim-app-users
