Inkscape Devel

Thread Start a new thread

Download

inkscape-devel@lists.inkscape.org

2 participants
12925 discussions

[0.41] Fix link: Move functions from splivarot.cpp to xml/
by Peter Moulder 06 Feb '05

06 Feb '05

A couple of utility functions in splivarot.cpp have become used by xml/repr-util.cpp. The attached patch moves these two functions (LCA and AncetreFils) to new files xml/repr-sorting.{cpp,h} in xml/libspxml.a. This is appropriate for cleanliness, and also fixes a link problem with `make check'. Since we're in hard freeze, I haven't renamed these functions. (N.B. Remember to do `cvs add -ko xml/repr-sorting.{cpp,h}' after applying this patch.) The patch (like the gc one, I should have mentioned in the previous message) is from the src directory. pjrm.

2 2

[0/5]: patches for clean "make check"
by Kees Cook 05 Feb '05

05 Feb '05

Following this email are five patch sets (whose apply order matters). This is a full roll-up of changes Peter and I worked on last night with some additional updates to get "make check" to fully pass. 1/5: compile cleanups only This is makefile goo for getting "make check" to compile correctly. 2/5: test code changes only This is test-code changes only. No core code changes are needed to make these tests pass "make check". 3/5: core code changes for repr-action-test compiling This is a change to the way core code is layed out in the tree, to help compile repr-action-test more easily. The functions are unchanged. 4/5: core code changes for repr-action-test behavior This changes when an undo session is released, down in simple-session. This lets repr-action-test pass its tests. The only caller to sp_repr_rollback is sp_document_cancel. sp_document_cancel isn't easily callable, since the three calls to it currently would only happen during repr tree breakage in the XML editor. I think this is safe. 5/5: win32 file list updates This is just a final sync of all the above file changes, as seen by the win32 file list building tools. "make check" finished, but "make distcheck" does not, as streamtest depends on files local to its directory, which is against build rules for "distcheck". I will fix it later, since I made it relocatable in patch #2. -- Kees Cook @outflux.net

4 4

[4/5]: core code changes for repr-action-test behavior
by Kees Cook 05 Feb '05

05 Feb '05

attached. -- Kees Cook @outflux.net

3 2

[1/5]: compile cleanups only
by Kees Cook 05 Feb '05

05 Feb '05

attached. -- Kees Cook @outflux.net

2 1

[5/5]: win32 file list updates
by Kees Cook 05 Feb '05

05 Feb '05

attached. -- Kees Cook @outflux.net

1 0

[3/5]: core code changes for repr-action-test compiling
by Kees Cook 05 Feb '05

05 Feb '05

attached. -- Kees Cook @outflux.net

1 0

[2/5]: test code changes only
by Kees Cook 05 Feb '05

05 Feb '05

attached. -- Kees Cook @outflux.net

1 0

RE: [Inkscape-devel] Inkboard linking/dependencies
by Montgomery, Steven S 05 Feb '05

05 Feb '05

I've went ahead and included the extern lines: however, that's a different issue than what we were having. The undefined reference we have is to functions we wrote in inkboard.cpp. Here they are from the most recent attempt: dialogs/libspdialogs.a(InkboardMsg.o)(.text+0xa7a): In function `sp_inkBMsg_ObjectAddedChild': dialogs/InkboardMsg.cpp:436: undefined reference to `sendChange(char*)' dialogs/libspdialogs.a(InkboardMsg.o)(.text+0xc92): In function `sp_inkBMsg_ObjectRemovedChild': dialogs/InkboardMsg.cpp:519: undefined reference to `sendChange(char*)' dialogs/libspdialogs.a(InkboardMsg.o)(.text+0xe4d): In function `sp_inkBMsg_ObjectChanged': dialogs/InkboardMsg.cpp:624: undefined reference to `sendChange(char*)' dialogs/libspdialogs.a(inkboard-connect.o)(.text+0xa97): In function `sp_inkboardConnect_dialog_inkboardConnect(_GObject*, _GObject*)': dialogs/inkboard-connect.cpp:228: undefined reference to `connect_and_auth(char*, char*, char*)' dialogs/libspdialogs.a(inkboard-connect.o)(.text+0xacf):dialogs/inkboard -connect.cpp:238: undefined reference to `setRecipient(char const*)' dialogs/libspdialogs.a(inkboard-connect.o)(.text+0x138f): In function `sp_inkboardConnect_dialog_inkboardShareUser(_GObject*, _GObject*)': dialogs/inkboard-connect.cpp:393: undefined reference to `send_connect_request_to_user(char const*, char*)' I suspect you didn't get that error when you checked out of the CVS. Line 8 of inkboard.cpp should be #include "dialogs/InkboardMsg.h" instead of #include "dialogs/InkboardMsg.cpp". I hesitate to upload that change since we've been following the convention of only committing changes after we ensure that it at least compiles. For a reason I don't fully understand, including that .cpp somehow informs the linker of where our new functions are defined. Thanks for the help on this. Steven -----Original Message----- From: inkscape-devel-admin(a)lists.sourceforge.net [mailto:inkscape-devel-admin@lists.sourceforge.net] On Behalf Of Bryce Harrington Sent: Friday, February 04, 2005 1:43 AM To: Montgomery, Steven S Cc: inkscape-devel(a)lists.sourceforge.net Subject: RE: [Inkscape-devel] Inkboard linking/dependencies On Thu, 3 Feb 2005, Montgomery, Steven S wrote: > No, we don't have our code linking normally. Since it was such a > brickwall for our progress, we moved the Jabber code into a file we > added under dialogs(where it was being called from). Obviously this > links, but we definitely would like to separate the code back out how it > should be. > > I've seen some recent posts about automake 1.9 causing problems for some > people. Perhaps that is our issue as well? Okay, I think we got this one figured out tonight. Check out our discussion in today's jabber logs here: http://inkscape.gristle.org/2005-02-03.txt Basically, loudmouth is set up to link in C style but since Inkscape is C++, libs are linked in C++ style. You can direct the linker to link the loudmouth functions in C style like this: diff -p -u -r1.4 inkboard.h --- inkboard.h 3 Feb 2005 20:19:33 -0000 1.4 +++ inkboard.h 4 Feb 2005 06:21:55 -0000 @@ -1,7 +1,10 @@ //Inkboard.h +extern "C" { #include <loudmouth/loudmouth.h> +}; + //#include "inkboard-TimedMessageNode.h" #define TEST_RECEPTION 1 Bryce ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2 1

[0.41] Possible bezier test fix
by Peter Moulder 05 Feb '05

05 Feb '05

As mentioned on jabber, i haven't even *compiled* this patch yet, let alone checked whether it fixes the test failure. I send it now because it's bed time, and it'll take a while on this machine to compile with optimization enabled. (The test doesn't fail without optimization enabled, on my machine.) As usual, the patch is relative to the src/ directory. pjrm.

1 0

0.41 "make check" progress
by Kees Cook 05 Feb '05

05 Feb '05

Peter and I managed to nail down almost all the issues with "make check". This patch includes Peter's earlier ones, and is almost entirely changes to test code, or Makefile goo. There are still two tests failing (and unless they're simple, I would vote to ignore them, since I'm not sure they were run for the 0.40 release... anyone know?) src/xml/repr-action-test src/display/bezier-utils-test I'll try to get 0.41pre1 packaged tomorrow. (This patch does not, however, include mental's update, which I think looks fine to go in.) -- Kees Cook @outflux.net

1 0

[0.41] Fix style-test failure
by Peter Moulder 05 Feb '05

05 Feb '05

The attached patch makes style-test pass. style-test.cpp hadn't been updated for Bulia's addition of basic support for the `overflow' property in style.cpp v1.80. Rationale for inclusion in 0.41: i) Safety: Touches only a regression test, not inkscape/inkview themselves. ii) Needed (though not sufficient) for `make distcheck' / `make check' to work. Suggested cvs comment: Minimal update for supporting overflow property. (Doesn't test overflow, just updates expected result of existing tests.) Again, the patch is relative to the src/ directory. pjrm.

1 0

[0.41] Move gc-related files to libinkpost.a, for `make check'
by Peter Moulder 05 Feb '05

05 Feb '05

libinkpost.a is supposed to contain files needed by subdirs, according to the comment. In particular, a few unit test programs in subdirectories link against libinkpost.a but not libinkpre.a. It seems useful to maintain this distinction: reduced link times, and it facilitates debugging of some link-related bugs (e.g. the recent mips problem) to have different executables link against different subsets of the .a files. The attached patch moves gc-related files from libinkpre.a to libinkpost.a. According to nm, the relevant two .o files (gc.o and gc-anchored.o) don't depend on any other object files, whereas very many files depend on gc-anchored.o, and many of the main-containing files depend on gc.o. pjrm.

1 0

Hard Freeze for 0.41 Release
by Bryce Harrington 05 Feb '05

05 Feb '05

As of now, 11:00pm PST 2/4/05, Inkscape is in "Hard Freeze" mode. During this phase, no commits to CVS are allowed without formal approval from the "Freeze Wardens". For this release, the Freeze Wardens are Bulia Byak and Kees Cook. Both must okay any change to the codebase (including changes that they themselves create). The fundamental idea behind a Hard Freeze is to slow down changes to the codebase, and achieve some quiescence to give room for the changes specifically needed to ensure a quality release. This also allows each of us to doublecheck the final code to make sure all the i's are dotted and t's crossed. If you feel it is critical to get a last minute change in, that's fine. Please submit them as patches (using 'cvs diff -puN') and email them to the Freeze Wardens for review and incorporation (or postponement) at their discretion. The Freeze Wardens will decide when the Hard Freeze is over. They will establish a branch tag and declare it ready for release. It is assumed this may take a few days but less than a week. Once the code is branched and tagged, the Hard Freeze will end, and the Release Phase will begin. The release branch will be used for preparing packages, while the mainline branch will be returned to regular open development. Bryce

1 0

no xmlns crash
by Aaron and Sarah Spike 05 Feb '05

05 Feb '05

I have some files created by hand and some generated by batik that crash on loading. From what I can tell the crash is caused because my files don't have xmlns="http://www.w3.org/2000/svg" in the svg tag. The files cause no trouble with the adobe plugin. Requiring the namespace declaration is great. Inkscape should reject improperly formed files with out crashing right? Aaron Spike

5 5

Re: win32 GTK
by Bob Jamison 05 Feb '05

05 Feb '05

Actually, I was considering something radically different.. If it is possible, it would be good if we could build the entire tree from source ourselves with the cross-compiler (or maybe mingw). Then we could have any configuration we want, and not need to beg & borrow dll's from other people. Does this sound like an idea? Bob Kees Cook wrote: >Hey Bob. I was looking at the GTK packaged for Gimp, Ethereal, and >Gaim, and was thinking about trying to switch to it (after the 0.41 >release). Have you looked at this at all? It looks like it may fix a >number of weird problems we've had. > > >

3 2

Coming Hard Freeze tonight
by Bryce Harrington 04 Feb '05

04 Feb '05

It sounds like we're about ready for going into the final Hard Freeze, so I'd like to propose we do so in 12 hours from now: 11pm PST 2/4. During the Hard Freeze, no changes to CVS should be made without review and approval. Work should be limited to critical bug fixes, packaging, and release-related activity only. I think it was effective to have a pair of reviewer/approvers to keep an eye on the codebase for the hard freeze period in the 0.40 release. Last time, mental and bulia performed this function. For this release, I'd like to ask bulia and kees to perform this function. I know mental has been extremely busy with work, so I suspect he'd like to conserve what Inkscape time he has for finishing up his own work. Kees has been extremely active in bug fixing this release, so I think he'd be an excellent person for this role. (Maybe we can make this a rotating position for future releases.) Bryce

4 8

honoring presserveAspectRatio
by Edward Flick 04 Feb '05

04 Feb '05

Hello everyone, Is the freeze tonight going to mean that there will be no more added features until 1.0? Or just a feature freeze for 4.1? Also, I have just posted a suggestion on the list that the preserveAspectRatio attribute be added/honored. I wouldn't mind doing this myself, although I am new to the project and could use a couple of pointers on where I should make the necessary changes. Would anyone be interested in this? Ed

2 1

Italian translation
by Luca Bruno 04 Feb '05

04 Feb '05

Hi all, here you can find the updated Italian Translation of Inkscape. It is complete and with updated pot (today's CVS). Please upload it in time for 0.41. Ciao, Luc@ [CC'ed Arpad Biro as in previous private emails] -- .''`. ** Debian GNU/Linux ** | Luca Bruno : :' : The Universal O.S. | luca.br(AT)uno.it `. `'` | GPG Key ID: 3BFB9FB3 on keyserver.linux.it `- http://www.debian.org | Proud Debian GNU/Linux User -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Assicurazione auto Zuritel. Fai un preventivo gratuito e scopri il risparmio e molto di pi�! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=3175&d=4-2

2 1

Some suggestions for the fill and stroke dialog
by Andreas Nilsson 04 Feb '05

04 Feb '05

Dear Inkscape developers. The current fill and stroke dialog is a big dialog that takes up 1/4 of my screen and has lots dirrerent of stuff in it. I'll try explain some of it's problems trough a short user case. --- Joakim is a graphic designer. He makes a lot of illustrations for different clients and is under a constant time pressure. He is currently working on a project where the AD has decided that they will use flat colors and stokes of varying width. 1. Joakim has the fill and stoke dialog up most of the time. It is space consuming and he has to move it constantly or hide it in order to see his artwork. 2. He has to do a huge amount of clicks because he moves between fill style and fill color all the time. 3. He is working in RBG color space, but has the ability to choose CMYK, even if the document is not in that color space. This confuses him. 4. He do not use dash pattern at all for this project. This only takes up space for him. 5. The markers are hard to overview (this is not really important for Joakim right now, but it might be in his next project). --- I have thought about these problems for a while and come up with a quick mockup with some ideas. http://ramnet.se/~nisse/diverse/temp/new_dialogs_mockup.png What I have done in this mockup is: - Splitted up the current dialog into smaller dialogs for better customization to suit an artists current workflow. - The font size is set to small to make the dialogs a bit narrower. - All dialogs are equally wide to make them easy to line up. - If the document is in the cmyk color space, it only shows the cmyk color settings. - I guessed most people uses the stroke width more than the other settings in this dialog and put the more rarely used options in an expander. - The markers are in their own dialog as well, and structured in a way that makes them easier to overlook. Names could be displayed when the mouse hoover over a marker. BTW. I know this looks a lot like Adobe Illustrator. And yes, I am very accustomed to the interface of that program, and am a bit inspired by it. But hopefully this can spur some discussion on how to better handle the color and stroke dialog/dialogs - Andreas Nilsson

10 11

[Fwd: Re: [office] [Fwd: clarification: OpenDocument and SVG]]
by Jon Phillips 04 Feb '05

04 Feb '05

Check it out! Progress on getting on w3.org's svg pages... Jon -------- Original Message -------- Subject: Re: [office] [Fwd: clarification: OpenDocument and SVG] Date: Fri, 4 Feb 2005 08:39:35 -0800 From: Chris Lilley <chris@...157...> Reply-To: Chris Lilley <chris@...157...> Organization: W3C To: Jon Phillips <jon@...235...> References: <4200ABF1.3010700@...677...> <4200C4A8.1030306@...678...> <4207e7a9.832074890@...689...> <1107368323.42011983e384f@...660...> <420139A2.3010603@...235...> <4201F976.8060306@...678...> <6610279990.20050203052414@...157...> <42033698.2050504@...235...> On Friday, February 4, 2005, 12:47:20 AM, Jon wrote: JP> Chris Lilley wrote: >> On Thursday, February 3, 2005, 2:14:14 AM, Michael wrote: >> >> MB> I believe that we will be able to resolve this issue in a way that is >> MB> beneficial to both the OpenDocument and SVG specs and agree that we >> MB> should keep the communication channels open. Who in the SVG group could >> MB> be the primary contact for the OpenDocument TC? Is it you? >> >> Jon Phillips is not a member of the SVG WG. I am the chair of that WG, >> so the contact can be through me. The issue is going to be discussed at >> todays telcon (in 40 minutes time ...) but its possible that we will need >> more time, and more communication between the two groups, to resolve >> this successfully. I gather there is a hard deadline of this Friday for >> comments? >> >> >> MB> I'd also like to thank Mental for bringing this topic to the attention >> MB> of our two working groups. >> >> Yes, a very timely alert - thanks! >> JP> Chris, could Inkscape (www.inkscape.org) and Open Clip Art Library JP> (www.openclipart.org) please get mentioned on the SVG portion of the W3C site. JP> We have been begging you guys for this off and on for a while. Please can we get JP> on some of your guys' pages as an SVG-based tool and a repository for SVG, JP> respectively. The implementation database is supposed to be run by an external SVG organization, as of a year ago. However, they do not seem to have done anything yet. This is irritating for implementors (and for myself, as people keep asking me to add stuff and i can't). I am meeting with those guys in 10 days time and will asked them about progress on this. if they haven't done it by then, i will get the database hosted somewhere else (like svg.org) which is where we syndicate our SVG news from. The idea (was) that implementors could update their own entries as they released new versions, so it would always be up to date but viewable from a central location. -- Chris Lilley mailto:chris@...157... Chair, W3C SVG Working Group Member, W3C Technical Architecture Group -- Jon Phillips USA PH 510.499.0894 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)

2 1

Article about Cairo
by Bob Jamison 04 Feb '05

04 Feb '05

Here is another item of interest: http://www.osnews.com/story.php?news_id=9609 Bob

1 0

input "preedit" handling disabled
by Kees Cook 04 Feb '05

04 Feb '05

While investigating bug 1086769, I discovered that inkscape's on-canvas text editing does not handle (some?) multi-byte character entry. Here's what I did... I installed "scim-chinese" and "scim-gtk2-immodule" which gives me an "SCIM" input module (right-click on text-entry widget to select SCIM). Then, you can hit ctrl-space to switch to chinese-char-entry mode, which lets you type a letter (say, "a") and then select (with numbers) which character you want. In the text widgets, this works great. On the canvas, inkscape would do VERY weird things: it would add the "preedit" character to the _end_ of the string instead of at the cursor position, and then when the final char was selected, it would overwrite the char AT the cursor position. Basically, the SPTextContext is attempting to handle the "preedit" character events itself, but it doesn't do it right. Since "preedit" handling doesn't seem to be _required_ for input to be processed, I've disabled it. This just means that the "predit" char isn't visible until you're done typing it in. What's weird is that other Input Modules (like, say "IPA") will show their preedit letters and inkscape seems to handle it correctly (type "a" "e" with the IPA IM, to see a merged "ae" character). Even with preedit disabled, this works on the canvas. So... I'm not sure why preediting is there at all, and I've disabled it. Can anyone find any reduced functionality as a result of this? Currently this _fixes_ chinese input (at least with SCIM), so I'd like to leave it like this until I can better understand the IM system. -- Kees Cook @outflux.net

3 3

Re: [Inkscape-devel] Some suggestions for the fill and stroke dialog
by bulia byak 04 Feb '05

04 Feb '05

On Fri, 04 Feb 2005 12:11:06 +0100, David Christian Berg <david@...407...> wrote: > > - a current color indicator (like the one in the "color selector" in > > your mockup), except that it must not be in any dialog, but at the > > bottom of the main toolbar, on on the left of the horizontal palette > > Hmm, from Adobe I'm used to having it under the main toolbar, an it's > make sense to be there, but with the current layout it would be too > small. It doesn't need to be that big. Just a square with a border. Our main toolbar is wide enough for it I think. > So maybe I'd just put two buttons in front of the color-selection > bar/palette at the bottom.I think that would make a lot of sense. Possible, too. > > With these, 90% of reasons to open fill&stroke will be eliminated, and > > its size won't matter much anymore. > > Well, you'll still have to have a dialog to change the colors (opening > via double click) If our default palette has some common colors, changing them will be unfrequent. > and you'll have to have a dialog for stroke stuff. Also unfrequent with the exception of stroke width. > Concerning the CMYK vs RGB argument, Andreas gave: I think it should be > a drop down, because you've gotta be able to define RGB colors, even > when you're in a CMYK document, but the standard of the drop down has to > be set by document prefs. I don't care "what kind of document is this". Inkscape is a design tool, not prepress tool. I want the color mode which is the most convenient for me to THINK IN, and most often this is either HSV or wheel. If after I create my design I need to convert it to CMYK for some reason, I can use other tools for that. The CMYKness of a document must not affect my design process. The fact that in Adobe products it DOES affect it, is one of the main problems I have with those products. > > With palette, you click to change fill, shift+click to change stroke > > (same as the dropper tool now). Again, using fill&stroke for this will > > be much less frequent, so there's no need to break it up. > > (There also should always be one empty color field to add new colors Not empty, but a "duplicate color" command in the right-click menu of the swatches. > and > you'll have to be able to drag colors within the pallete. Yes > Furthermore: > have a Inkscape setting to have _no_ colors in the palette at startup. > That's the way I'm working, predefined colors (other than black and > white) are unnecessary for me and hinder the workflow, while other > people might want to have them.) Yes, though new users should see a complete enough palette by default > Point is that maybe this should be a document setting, Right now it is more of an Inkscape setting, because the color selector remembers the tab you used last. And I like it this way. It's not like length units which indeed may be different per document; colors are just colors everywhere. > Hmm, disagreed. Put the other stroke stuff into an expander like in the > mock-up, so that you can hide and show it easily, when you need it. In > general I don't like the idea being able to do the same thing at > multiple places. Exactly, this is what we need - one "quick" way to do something and one "complete" way to do the same. Like the quick layer selector and the layer dialog. I see absolutely no problem with this. Changing stroke width is such a common operation that it MUST be in the window interface somewhere. > I'm not yet sure, how the selector in the mock-up is supposed to work. > Wouldn't it make sense if it had tabs at the top for switching between > start, join and end markers? Yeah, probably, details need to be worked out, what I like however is the two-dimensional table instead of drop-down menu. > Or maybe you should just have a Markers > dialogue without any lines shown in the preview and you drag them and > drop them into the stroke-style dialogue as start, join or end > marker.... I think that would make a lot of sense, because that way you > can easily use any marker anywhere. As opposed to what? Can't you now use them anywhere? > > SVGs version 1.1 documents cannot use CMYK at all, so this is > > irrelevant. The CMYK selector is just a convenience. And then, even if > > I have a CMYK document of some kind, why on earth can't I use HSV or > > RGB to find a color I want, and have it converted to CMYK by the > > program? > > It's true, but for some reason graphic programs usually distinguish a > little stronger between the color spaces. I really hate that. I think the reason is that most of those programs are just old, and were initially paper-oriented, and thus keep sticking to their old superstitions even though they are mostly irrelevant today. > > Separating markers does make sense, though maybe not into a dialog but > > into a new tab in fill&stroke. > > hmm, that make me think of something. why not put everything in separate > tabs? Like [stroke weight], [caps and joins] (including miter limit -- > miter limit needs a spinbox!), [pattern] (this might as well get more > options like in Corel, where you can define your own pattern styles) and > [markers]. Possible too, but only if we use icons only, not words, for tab headers, otherwise they won't fit. > Hmmpff, the quick layer selection?? Maybe it's a good idea, once there > is another layer/objects dialogue, but as is right now, I haven't yet > managed to make layers part of my workflow. I only notice them, when for > some strange reason I can't move one object behind another. I use layers all the time and I really cannot imagine how I lived without them. Yes, there are some operations that are difficult and clumsy with the quick layer selector, but for many simple common operations it is very convenient and natural, indeed more natural than the layer dialogs in other apps.

2 2

versioning consensus
by unknown＠example.com 04 Feb '05

04 Feb '05

Incidentally, had we ever reached a consensus on calling this release 0.41.0 rather than 0.41? A _LOT_ of people seem to be reading 0.40 as 0.4.0, so making the .0 explicit would remove the ambiguity... -mental

4 3

Another Inkscape mention
by Bob Jamison 04 Feb '05

04 Feb '05

Hi, all, Saw an article mentioning Inkscape on Newsforge today: http://software.newsforge.com/software/05/02/02/215259.shtml Bob

1 0

Jump to page: