submitter says that it works in OpenOffice.org 3.2.1

Urk. Lubos, any chance you could look into this? AndrewMacro is btw notorious for breaking OOo/LibO. ;)

3.2.1 is just as broken here.

[Reproducible] with "LibreOffice 3.3.0Beta3 - WIN XP DE [OOO330m9 (build 3.2.99.2)]" and my own master documents with app. 90 pages. 

It's not simply reproducible with a 50 pages text document with a word art in it, but with documents containing complex layout. 
I tried attached app 850 pages "Lorem Ipsum" document with some fontwork and was able to reproduce the problem (or something similar?).

When I open the document, I see on page 830 a heading in the middle of the page 
announcing that this would be page 830. When I try to export this page I got attached sample2.pdf, what shows an other page.
During / after export I observed some "Neuformatierung ..." in the status line, and after that my page with heading had page 833. This difference might have caused the export of the wrong page.

Please see test kit under a.m. URL!
Heading should be on page 830, but export of page 830 will show an other page and will "shift" the heading to an other page No (833)

I believe my test kit shows some other problem than the reported one.
Currently PDF export from my Master Documents is completely unusable because of that wrong page export problem. My Documents have app. 50 pages and the effect differs from the one in comments from  Rainer Bielefeld 2010-11-20, Page numbers will not be modified after export.
I will try to create a sample document.

I can confirm that this issue remains in LibO RC2 for windows.

Created attachment 41990 [details]
Export result, pages 29 to 38

Created attachment 41991 [details]
Export result: page 29

Created attachment 41992 [details]
Export result: selection in p29

I tried this on the latest RC3 for windows and the results are as follows:

1) Exported pages 29 to 38
   => Got pages 30 to 39, with bookmarks from pages 29 to 38
2) Exported just page 29
   => Got page 30, with bookmarks of page 29
3) Exported just a selection of page 29
   => Got the right selection exported, but numbered list reset to 1. Bookmarks where also reset but otherwise where OK.

So there seems to be an offset somewhere in the page rendering that does not occur when generating the bookmarks.

I think that fixing this bug is of high importance..

I am able to reproduce Chalo Alvarez J's result with attachment for 
Bug 34093 - Partial PDFEXPORT of particular Master Documents breaks hyperlinks

Steps to reproduce:
0. Unzip test kit
1. Open "MasterSampleAE.odm"
2. Go to range" _fehlersuche_Saia_WEB" (=physical page 5 ... 14)
3. Menu 'File > Print'
   Print dialog opens
4 Insert Page No 5 in Page selection pane below preview
  expected: Start page of range should be shown
  actual: second page of range shown, to get the start page, you have to #
          select page 4
          Print or export tests confirm, you will have to select pages 4 ...13
          to get an output from pages 5 ... 14

I will attach a screenshot with comments.

It's the same problem for printing and export to PDF

And yes, that problem has to be solved quickly, it's a regression to OOo 3.1.1, but I see the same problem with OOo 3.4-dev. Because OOo versions later than 3.1.1 were not suitable for my dayle use, I can't tell with what version the problem started.

And yes, especially for EXPORT (or fax printing) where you do not always see the result before the recipient will have seen it, this problem is critical.

Created attachment 43188 [details]
See Comment 13!

Modified expected Version due to date of report.
Modified Status due to facts

Hi Lubos, I'd like to try to work on this bug, do you alread have any hints? I'm afraid the cause is not directly in pdfwriter.cxx but in the writer selection code, is that correct? 

Cheers, 
Peter

I'm afraid the cause the code as a whole, because the code related to this seems to be an awful mess. It's that bad that I don't even remember much anymore, but the problem was simply that there are several places where the page range is handled and they seem to be not quite related to each other. The basic problem that is causing this bug is that removing empty pages means adjusting the pages to print and each of these places handle it differently (or not at all).

For starters you could go to http://opengrok.libreoffice.org and search for "PageRange" and "aPageRange", that shows some of those places. Not all, and not all shown are relevant here, from what I remember:
- sw/source/ui/uno/unotxdoc.cxx - notice that it gets the page range from the pdf dialog; IIRC this place is not directly relevant to this bug, but you can see that the SwEnhancedPDFExportHelper usage has bIsSkipEmptyPages passed and SwEnhancedPDFExportHelper::CalcOutputPageNum() adjusts pages according to this
- filter/source/pdf/pdfexport.cxx - this converts the page range to a selection of pages to print and IIRC in git log I could find that older version of the code did some adjustments there
- sw/source/core/doc/doc.cxx - there is some page range handling done too, but IIRC when I tried to trivially already fix it there, code that was called after this expected to still have unadjusted range and broke

You'll probably also need to spend some time tracking what calls what and how it handled the page range, either in a debugger or with debug output, and the sequence of calls was IIRC nowhere near trivial.

I'm sorry I cannot provide more information. This will possibly require finding out how the whole page range thing is handled and then maybe the simplest fix will be rewritting it to be more sensible. If you will need more help I suggest asking on the libreoffice-devel mailing list as probably somebody of the developers who have spent more time with this codebase know better how the print handling works.

I have found a workaround to get the correct behaviour. In the "PDF Options" dialog box, you need to tick the "Export automatically inserted blank pages". This should be turned on by default.

The behaviour if you do not select this option is however still erratic. It should remove the blank pages, but not shift the page range in unpredictable ways.

thoughts on changing the default here appreciated. Ultimately, the whole 'Page' thing is a nightmare - people would presumably assume that page numbers could easily mean the numbers printed on each page - but that too is not necessarily so ;-)

Michael asked on libreoffice-ux-advice and I provided a more general answer on page numbers and their use for print and export (I hope I got the problem right). In a nutshell: changing the "empty pages" export option will cause other problems.

http://lists.freedesktop.org/archives/libreoffice-ux-advise/2011-September/000266.html

(In reply to comment #18)
> I have found a workaround to get the correct behaviour. In the "PDF Options"
> dialog box, you need to tick the "Export automatically inserted blank pages".
> This should be turned on by default.
> 
> The behaviour if you do not select this option is however still erratic. It
> should remove the blank pages, but not shift the page range in unpredictable
> ways.

Interesting. The PDF export dialog and print dialog differ in terms of page number handling. The print dialog bases upon document page numbers (and ignores empty pages), the PDF export dialog first removes the empty pages and recalculates the page range to be selected from.

At least this should be harmonized to work like printing.

this is LibO 3.4.x oldest most annoying bug.
I wonder if there has been any progress fixing it.

So... Summing this up.

1. PDF export is not buggy - it deliberately has the different (from printing) default setting: unchecked "Export automatically inserted blank pages". If you uncheck the respective "Print automatically inserted blank pages" in the print dialog - you will have the same confusing result.

2. The page counting is confusing - it do not count "automatically inserted blank pages" (for example, AndrewMacro: page 24). 

What to do:

* Change the page counting logic: count blank pages in any case.
  Requirements:
   * Handle these blank pages in the print dialog.
   * Provide a preview for the PDF export dialog.
      -> Reuse the print dialog. But:
          - Fit all the PDF option set (a lot of optional tab pages?).
          - No printer selection.
          - No "Number of copies"
          - No "page layout" tab.
         [- And no knowledge of the code around.]

This definitely does not fit into a bugfix release. :( 
  - A task for 3.6? 
  - Skip my "requirements" for now?

--
* PDF export dialog: filter/source/pdf/impdialog.cxx
* Print dialog: vcl/source/window/printdlg.cxx

Someone, who can tet it??

Thanks

(In reply to comment #23)
> So... Summing this up.

We will limit this bug to the summarized problem. For anything else not related to the "blank pages" thingy I will created different reports and obsolete Attachments here (for example my "See Comment 13!").

*** Bug 47678 has been marked as a duplicate of this bug. ***

NOT reproducible with "LibreOffice 3.5.2.2 German UI/Locale [Build-ID: 281b639-6baa1d3-ef66a77-d866f25-f36d45f] on German WIN7 Home Premium (64bit) and Debian sample from <http://www.pitonyak.org/AndrewMacro.odt>

I opened document and printed first Index Page (for me Page number 495) as sheet 513 (shown in status bar) to FreePDF, 1x with blank pages, 1x wo. blank pages. Both times correct contents shown in result.pdf

We had so many theories, Summary modifications here, May be it would be use this one here and open new Bugs with clear limitations for related problems still 
existing with 3.5.2.

3.4 lifecycle is terminated

@All:
What do you think about closing this Bug as suggested?

if it's not reproducible with 3.5.2 it should be closed

Thanks for additional testing
Due to last comment, changing status to WorksForMe

If problem will appear again, please, change status to Reopened

But It still does not really work for me, I still have problems with PDF export, have to select other pages than shown in preview for print. But that seems to have other reasons, I will have to submit a different bug for that.

Created attachment 118999 [details]
The original test document

I attached the test document from description in case it would be unavailable from the external link.

I can reproduce this issue with LibreOffice 5.0.1 from Debian. I am sure that it is a bug because current behaviour is unexpected.

Anyway, the importance of this bug is not high critical.

NEW per comment 32.

Hi Lubos,
I'm setting this ticket back to NEW as it has been inactive for more than 3
months.
Feel free to assign it back to you if you're still working on this.
Regards

I would guess that bug 95658 is related to this bug.  The whole problem seems to be that LO wants to keep re-formatting every time something is done.  If a page update is done by doing a Tools | Update | Page formatting, then why does it need to reformat, and not only just re-format, but change the previous format and therefore the page numbers every time a document is printed or exported to PDF?  You should be able to do a page format and be able to depend on the results of that for what it will look like when you print or export to PDF, but you can't.

Still present in LibreOffice 6.1.0.3 (W10/x64)

Still exists in version LibreOffice 6.3.0.0.alpha0+(x64)

Still exists in LibreOffice x
I exported a select set of pages and "Export as pdf" and "Print-> Microsoft Print to PDF". Both types of export have the same problems for my 550 page LO Writer document. 

For example, print to pdf resulted in a sequence of page numbers 164-165-164-165-164-.... 

In another case, I got page numbers 217-220-219-220-219-... in the exported pdf

In yet another case, when I did not start the PDF export from the start of a chapter, I got as PDF page numbers: 550, 547, 550, 547, 550, ...

Exporting the entire document to pdf does not seem to have this issue.

This is quite inconvenient not only for myself but also when I send PDF documents to other parties for review.

I forgot to add the Windows x64 LO version in my last comment, which is 6.2.0.3.

This bug has become WFM -- because of resolution of bug 52316.

1.  Open original test document.
2.  (wait a while -- it takes time for the page numbering to update) 
    Statusbar shows:  Page x of 540 (Page q of 523 to print) 
3.  Choose page range to export, using (the q values in the parentheses)

Actual result:  able to export desired pages (on first try) (even though the "q" values do not correspond to the page numbers in the document or the "x" values)

tested with:

Version: 7.0.0.0.alpha0+ (x64)
Build ID: dfd027342e6b4107ebd3369de96ef2be3883724d
CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: GL; VCL: win; 
Locale: en-US (en_DK); UI-Language: en-US
Calc: CL