I saw nothing unexpected with server installation of "AOO 4.1.0-dev – English UI / German locale - [AOO410m14(Build:9760)  -  Rev. 1583418_2014-04-02]" on German WIN7 Home Premium (64bit)", own separate user profile. May be I do not understand the problem?
(a) Chart + blank page?
(b) Chart on blank page?
(c) Something else?

@Edwin
Please attach a sample source document and your export result.

Created attachment 83185 [details]
PDF result

Source is attachment of issue 124647

I can not reproduce with
AOO420m1(Build:9800)  -  Rev. 1586681
Rev.1586681
Win 7
-> Linux only

The effect is reproducible with server installation of "AOO 4.1.0-dev – English UI / German locale - [AOO410m14(Build:9760)  -  Rev. 1583418_2014-04-02]" on German WIN7 Home Premium (64bit)", own separate user profile.

But it's not a bug, the result is correct. The chart width exceeds the page width and so the chart will be printed on 2 pages.

If you see differences between WIN and Linux they might be related to different settings, fonts or similar.

Chart was adjusted to fit one page in both Debian and Win 7.

(In reply to Edwin Sharp from comment #6)
> Chart was adjusted to fit one page in both Debian and Win 7.

how?

Legend was moved to chart bottom.
Chart was relocated below data.

(In reply to Edwin Sharp from comment #8)
I am not sure whether I understand, you did not mention that.
And that is unrelated, the chart width is smaller than the usable paper width. I think I found the problem, reproducible with server installation of "AOO 4.1.0-dev – English UI / German locale - [AOO410m14(Build:9760)  -  Rev. 1583418_2014-04-02]" on German WIN7 Home Premium (64bit)", own separate user profile.

(a) Problem is not related to PDF export, I see the same in 
    Print Preview.
(b) Problem is related not to Chart, also a same size rectangle
    will be printed on 2 pages
(c) I found the roots of the problem, it is related to the fact that 
    Calc will calculate an "effectively usable page width" based on
    columns what can be printed on 1 paper sheet, and this 
    "calculated page width" will (wrongly?) be used also for a print 
    (or PDF export) of a selected element
(d) Problem only seems to affect  such elements, but not cell ranges

I still need to do some research, final results and sample document covering all effects tomorrow!

Created attachment 83187 [details]
Sample document

Sample document has 2 sheets with 170mm usable page width.
Sheet2: Columns for first print page: sum width of columns larger than rectangle
        width, reported effect does not appear
Sheet2_2: Columns for first print page: sum width of columns LESS than rectangle
        width, reported effect DOES appear
Sheet3: I was not successful to get a similar effect with selected cells

(e) Already Reproducible with server installation of "Ooo 3.1.1 
    German WIN7 Home Premium (64bit) DE [OOO310m19 (Build 9420)]"

(f) Still Reproducible with server installation of "AOO 4.1.0-dev – English UI 
    / German locale - [AOO410m14(Build:9760)  -  Rev. 1583418_2014-04-02]" 
    on German WIN7 Home Premium (64bit)", own separate user profile.

(g) Also a problem with LibO 4.2

I suggest to close this issue as RESOLVED WONT FIX.

Reason: A Calc sheet is structured by columns and rows. And for this it makes no sense, to print a piece of a column/row onto one page and the rest of the column/row onto another page.

Simply open the page preview and close it. Then you will see, where the pagebreak is located.

2 solutions:
1) decrease the page margins
2) open the page format, tab Sheet:
 Scaling mode: Fit print range(s) on number of pages, Number of pages: 1
(or something similar)

Created attachment 83385 [details]
Additional Sample

(In reply to mroe from comment #12)
Following current wording "selected cells" current behavior indeed is more or correct - with a juridical point of view.
But see "Issue 124694 - Caption for print range selection radio button should be "Selection" instead of "Selected Cells""!

Additionally for a selected shape (possibly anchored to page) the relation to cells is not very plausible from user's point of view. Print will ignore any other cell contents of cells defining the print range, also ignore "print page borders ...", so why should some empty cells define the print range?

Roots of current behavior might be in unknown fix for "Issue 3992 - Print Selection only works for selected cells, not other selected objects"

To me the current behavior seems "correct, but archaic".

Sorry oversaw the "Selection".

But yes, I see this behaviour also as "correct".

Simply suggest you have more as only one object selected. Should Calc print this selection _always_ at the most left and most top position (margins)? If so, you would never have the chance to place the objects at a defined position how you want at the page.