Pagination could be required in many different scripts and so a pagination class ought to be reusable without recoding. You need to make this much more abstract.
Arguments required by the paginator object should be defined in the calling script - don't attempt to do it inside the pagination class itself. What if you need to use a multi-table JOIN query? It's better to define the query string (minus the LIMIT clause) in the calling script and create a pagination class method which simply tacks on a LIMIT clause.
Also, I would recommend some extensive refactoring. Many methods in your code take on too much work: split them into small fns which have just one task.
An object design starts with the interface. What do you want from a paginator class?
(1) a (LIMIT) $query result resource
(2) a pagination hyperlink
..and nothing, but NOTHING else (well maybe a total num rows, should it be required).
Putting all that together, as well as a constructor and the above getters, you might define "private" methods as follows (which ought to be pretty much self-explanatory):
setTotalNumRows()
setTotalPages()
checkPageChoice() - (might not be valid)
setOffset()
setPagedQuery()
setPaginationLink()
The pagination class doesn't know or care what it's trying to paginate - and doesn't do anything else except paginate.
It's also maybe a good idea to parcel out the pagination link code into its own object (try a factory recall pattern - see phppatterns.com). That means you can create different classes for different types of link (next/previous, alphabetical, numeric whatever) and simply plug in whichever one you need for a script. Putting them all in one class creates unecessary bloat - only one will actually be used in a given script.
