質問する

Revision history [back]

click to hide/show revision 1
最初のバージョン

自信なし。解答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?

  • LibreOfficeのコードでは一旦twip単位でデータを取り出し、計算後twip単位に変換するような処理が入っている。
    https://opengrok.libreoffice.org/xref/core/cui/source/tabpages/swpossizetabpage.cxx?r=81260c44#1378

  • メインメニューから [ツール]→[オプション] と辿り、更にツリーから[LibreOffice Writer]→[全般]、右側[設定]に[使う単位]があってミリメートル、センチメートル、インチ、ポイント、パイカが選択可能だ。

  • Wikipediaによると、Twipの定義は「1Twipは1/20ポイントであり、1/1440インチに相当する。「Twentieth of an Inch Point」から、Twipと名づけられた。」だ。
    https://ja.wikipedia.org/wiki/Twip

  • そして、picaの定義は「パイカ(pica)は、印刷などに使用される長さの単位である。1パイカ=1/6インチ=12ポイントである。」だ。1440 / 6 = 240 、つまり1 Twipは1/240 picaである。
    https://ja.wikipedia.org/wiki/%E3%83%91%E3%82%A4%E3%82%AB

  • 以上から、1pica, 1point, 1Inchは全て単位がTwipであっても、十進整数で表すことが出来る!

  • 一方、1 Inch = 25.4 mm だから、1mm1cmはTwipで表しても、十進整数で正確に表すことはできないものが存在する!
    https://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%83%81

    • m_pWidthMFなどのメンバの型MetricFieldはmnDecimalDigits等で管理されており、SetDecimalDigitsで変更できるから一桁にしてこのケースについては確かに自然に見えるようにする、という修正は確かに可能だ。 https://docs.libreoffice.org/cui/html/classSvxSwPosSizeTabPage.html#aab617a527bf6e3fc9dfd406b68b268b0

    • 自分は特に考えていないが、このadhocな修正方法でどこかにregression出ないだろうか?何か根本的な解決策があれば乗るんだが…

自信なし。解答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?

  • LibreOfficeのコードでは一旦twip単位でデータを取り出し、計算後twip単位に変換するような処理が入っている。
    https://opengrok.libreoffice.org/xref/core/cui/source/tabpages/swpossizetabpage.cxx?r=81260c44#1378

  • メインメニューから [ツール]→[オプション] と辿り、更にツリーから[LibreOffice Writer]→[全般]、右側[設定]に[使う単位]があってミリメートル、センチメートル、インチ、ポイント、パイカが選択可能だ。

  • Wikipediaによると、Twipの定義は「1Twipは1/20ポイントであり、1/1440インチに相当する。「Twentieth of an Inch Point」から、Twipと名づけられた。」だ。
    https://ja.wikipedia.org/wiki/Twip

  • そして、picaの定義は「パイカ(pica)は、印刷などに使用される長さの単位である。1パイカ=1/6インチ=12ポイントである。」だ。1440 / 6 = 240 、つまり1 Twipは1/240 picaである。
    https://ja.wikipedia.org/wiki/%E3%83%91%E3%82%A4%E3%82%AB

  • 以上から、1pica, 1point, 1Inchは全て単位がTwipであっても、十進整数で表すことが出来る!

  • 一方、1 Inch = 25.4 mm だから、1mm1cmはTwipで表しても、十進整数で正確に表すことはできないものが存在する!
    https://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%83%81

    • m_pWidthMFなどのメンバの型MetricFieldはmnDecimalDigits等で管理されており、SetDecimalDigitsで変更できるから一桁にしてこのケースについては確かに自然に見えるようにする、という修正は確かに可能だ。 https://docs.libreoffice.org/cui/html/classSvxSwPosSizeTabPage.html#aab617a527bf6e3fc9dfd406b68b268b0

    • 自分は特に考えていないが、このadhocな修正方法でどこかにregression出ないだろうか?何か根本的な解決策があれば乗るんだが…

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?

  • LibreOfficeのコードでは一旦twip単位でデータを取り出し、計算後twip単位に変換するような処理が入っている。
    https://opengrok.libreoffice.org/xref/core/cui/source/tabpages/swpossizetabpage.cxx?r=81260c44#1378

  • メインメニューから [ツール]→[オプション] と辿り、更にツリーから[LibreOffice Writer]→[全般]、右側[設定]に[使う単位]があってミリメートル、センチメートル、インチ、ポイント、パイカが選択可能だ。

  • Wikipediaによると、Twipの定義は「1Twipは1/20ポイントであり、1/1440インチに相当する。「Twentieth of an Inch Point」から、Twipと名づけられた。」だ。
    https://ja.wikipedia.org/wiki/Twip

  • そして、picaの定義は「パイカ(pica)は、印刷などに使用される長さの単位である。1パイカ=1/6インチ=12ポイントである。」だ。1440 / 6 = 240 、つまり1 Twipは1/240 picaである。
    https://ja.wikipedia.org/wiki/%E3%83%91%E3%82%A4%E3%82%AB

  • 以上から、1pica, 1point, 1Inch1inchは全て単位がTwipであっても、十進整数で表すことが出来る!

  • 一方、1 Inch = 25.4 mm だから、1mm1cmはTwipで表しても、十進整数で正確に表すことはできないものが存在する!
    https://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%83%81

  • m_pWidthMFなどのメンバの型MetricFieldはmnDecimalDigits等で管理されており、SetDecimalDigitsで変更できるから一桁にしてこのケースについては確かに自然に見えるようにする、という修正は確かに可能だ。 https://docs.libreoffice.org/cui/html/classSvxSwPosSizeTabPage.html#aab617a527bf6e3fc9dfd406b68b268b0

  • 自分は特に考えていないが、このadhocな修正方法でどこかにregression出ないだろうか?何か根本的な解決策があれば乗るんだが…

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけ

  • LibreOfficeのコードでは一旦twip単位でデータを取り出し、計算後twip単位に変換するような処理が入っている。
    https://opengrok.libreoffice.org/xref/core/cui/source/tabpages/swpossizetabpage.cxx?r=81260c44#1378

  • メインメニューから [ツール]→[オプション] と辿り、更にツリーから[LibreOffice Writer]→[全般]、右側[設定]に[使う単位]があってミリメートル、センチメートル、インチ、ポイント、パイカが選択可能だ。

  • Wikipediaによると、Twipの定義は「1Twipは1/20ポイントであり、1/1440インチに相当する。「Twentieth of an Inch Point」から、Twipと名づけられた。」だ。
    https://ja.wikipedia.org/wiki/Twip

  • そして、picaの定義は「パイカ(pica)は、印刷などに使用される長さの単位である。1パイカ=1/6インチ=12ポイントである。」だ。1440 / 6 = 240 、つまり1 Twipは1/240 picaである。
    https://ja.wikipedia.org/wiki/%E3%83%91%E3%82%A4%E3%82%AB

  • 以上から、1pica, 1point, 1inchは全て単位がTwipであっても、十進整数で表すことが出来る!

  • 一方、1 Inch = 25.4 mm だから、1mm1cmはTwipで表しても、十進整数で正確に表すことはできないものが存在する!
    https://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%83%81

  • m_pWidthMFなどのメンバの型MetricFieldはmnDecimalDigits等で管理されており、SetDecimalDigitsで変更できるから一桁にしてこのケースについては確かに自然に見えるようにする、という修正は確かに可能だ。 https://docs.libreoffice.org/cui/html/classSvxSwPosSizeTabPage.html#aab617a527bf6e3fc9dfd406b68b268b0

  • 自分は特に考えていないが、このadhocな修正方法でどこかにregression出ないだろうか?何か根本的な解決策があれば乗るんだが…

大幅編集キャンペーン中(2018-03-22T05:25+0900) そのうちまるっと書き換えます。元の内容が見たいときは履歴で

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

  • * LibreOfficeのコードでは一旦twip単位でデータを取り出し、計算後twip単位に変換するような処理が入っている。 https://opengrok.libreoffice.org/xref/core/cui/source/tabpages/swpossizetabpage.cxx?r=81260c44#1378

    LibreOfficeのコードでは一旦twip単位でデータを取り出し、計算後twip単位に変換するような処理が入っている。 前記のURIはダイアログ側のものであって不適切。見るべきはこっち。
    https://opengrok.libreoffice.org/xref/core/cui/source/tabpages/swpossizetabpage.cxx?r=81260c44#1378https://github.com/LibreOffice/core/blob/44d5188b2fd8afc82aa8fda1ad4b374734129aea/svx/source/sidebar/possize/PosSizePropertyPanel.cxx#L365

    • メインメニューから [ツール]→[オプション] と辿り、更にツリーから[LibreOffice Writer]→[全般]、右側[設定]に[使う単位]があってミリメートル、センチメートル、インチ、ポイント、パイカが選択可能だ。

    • Wikipediaによると、Twipの定義は「1Twipは1/20ポイントであり、1/1440インチに相当する。「Twentieth of an Inch Point」から、Twipと名づけられた。」だ。
      https://ja.wikipedia.org/wiki/Twip

    • そして、picaの定義は「パイカ(pica)は、印刷などに使用される長さの単位である。1パイカ=1/6インチ=12ポイントである。」だ。1440 / 6 = 240 、つまり1 Twipは1/240 picaである。
      https://ja.wikipedia.org/wiki/%E3%83%91%E3%82%A4%E3%82%AB

    • 以上から、1pica, 1point, 1inchは全て単位がTwipであっても、十進整数で表すことが出来る!

    • 一方、1 Inch = 25.4 mm だから、1mm1cmはTwipで表しても、十進整数で正確に表すことはできないものが存在する!
      https://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%83%81

    • m_pWidthMFなどのメンバの型MetricFieldはmnDecimalDigits等で管理されており、SetDecimalDigitsで変更できるから一桁にしてこのケースについては確かに自然に見えるようにする、という修正は確かに可能だ。 https://docs.libreoffice.org/cui/html/classSvxSwPosSizeTabPage.html#aab617a527bf6e3fc9dfd406b68b268b0

    • 自分は特に考えていないが、このadhocな修正方法でどこかにregression出ないだろうか?何か根本的な解決策があれば乗るんだが…

大幅編集キャンペーン中(2018-03-22T05:25+0900) そのうちまるっと書き換えます。元の内容が見たいときは履歴で2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

* LibreOfficeのコードでは一旦twip単位でデータを取り出し、計算後twip単位に変換するような処理が入っている。 https://opengrok.libreoffice.org/xref/core/cui/source/tabpages/swpossizetabpage.cxx?r=81260c44#1378

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

前記のURIはダイアログ側のものであって不適切。見るべきはこっち。
https://github.com/LibreOffice/core/blob/44d5188b2fd8afc82aa8fda1ad4b374734129aea/svx/source/sidebar/possize/PosSizePropertyPanel.cxx#L365
で、以下、やや推測込み。

    例えば

    1. メインメニューから [ツール]→[オプション] と辿り、更にツリーから[LibreOffice Writer]→[全般]、右側[設定]に[使う単位]があってミリメートル、センチメートル、インチ、ポイント、パイカが選択可能だ。

      Writer起動
    2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
    3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
      https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
    4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
      https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
      869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
    5. Wikipediaによると、Twipの定義は「1Twipは1/20ポイントであり、1/1440インチに相当する。「Twentieth of an Inch Point」から、Twipと名づけられた。」だ。
      https://ja.wikipedia.org/wiki/Twip

    6. そして、picaの定義は「パイカ(pica)は、印刷などに使用される長さの単位である。1パイカ=1/6インチ=12ポイントである。」だ。1440 / 6 = 240 、つまり1 Twipは1/240 picaである。
      https://ja.wikipedia.org/wiki/%E3%83%91%E3%82%A4%E3%82%AB

    7. 以上から、1pica, 1point, 1inchは全て単位がTwipであっても、十進整数で表すことが出来る!

    8. 一方、1 Inch = 25.4 mm だから、1mm1cmはTwipで表しても、十進整数で正確に表すことはできないものが存在する!
      https://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%B3%E3%83%81

    9. m_pWidthMFなどのメンバの型MetricFieldはmnDecimalDigits等で管理されており、SetDecimalDigitsで変更できるから一桁にしてこのケースについては確かに自然に見えるようにする、という修正は確かに可能だ。 https://docs.libreoffice.org/cui/html/classSvxSwPosSizeTabPage.html#aab617a527bf6e3fc9dfd406b68b268b0 ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

    10. 自分は特に考えていないが、このadhocな修正方法でどこかにregression出ないだろうか?何か根本的な解決策があれば乗るんだが…もう一度コンストラクタを見てみよう。 mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
      mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
      mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
      mpBindings->Update( SID_ATTR_METRIC );
      の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
      よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
      Writerで用いる単位を設定画面からセンチメートルにしていた場合
      MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
      mpBindings->Update( SID_ATTR_METRIC );
      mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
      mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
      mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
      となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

で、以下、やや推測込み。

例えば

  1. Writer起動
  2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
  3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
  4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
    869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
  5. ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

  6. もう一度コンストラクタを見てみよう。 mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    mpBindings->Update( SID_ATTR_METRIC );
    の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
    よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
    Writerで用いる単位を設定画面からセンチメートルにしていた場合
    MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
    mpBindings->Update( SID_ATTR_METRIC );
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

で、以下、やや推測込み。

  1. Writer起動
  2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
  3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
  4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
    869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
  5. ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

  6. もう一度コンストラクタを見てみよう。 もう一度コンストラクタを見てみよう。
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    mpBindings->Update( SID_ATTR_METRIC );
    の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
    よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
    Writerで用いる単位を設定画面からセンチメートルにしていた場合
    MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
    mpBindings->Update( SID_ATTR_METRIC );
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

で、以下、やや推測込み。

  1. Writer起動
  2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
  3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
  4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
    869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
  5. ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

  6. もう一度コンストラクタを見てみよう。
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    mpBindings->Update( SID_ATTR_METRIC );
    の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
    よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
    Writerで用いる単位を設定画面からセンチメートルにしていた場合
    MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
    mpBindings->Update( SID_ATTR_METRIC );
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-14 追記: 原因の想像はついたけど、治し方が頭の中で固まらない

2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

で、以下、やや推測込み。

  1. Writer起動
  2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
  3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
  4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
    869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
  5. ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

  6. もう一度コンストラクタを見てみよう。
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    mpBindings->Update( SID_ATTR_METRIC );
    の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
    よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
    Writerで用いる単位を設定画面からセンチメートルにしていた場合
    MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
    mpBindings->Update( SID_ATTR_METRIC );
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-14 追記: 原因の想像はついたけど、治し方が頭の中で固まらない

いや、わかってないのか。とりあえず調査の過程でこれでいいのか少なくとも一箇所自信がない場所がある。
https://opengrok.libreoffice.org/xref/core/sw/source/core/layout/pagechg.cxx?r=d36f7c5b#2359

2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

で、以下、やや推測込み。

  1. Writer起動
  2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
  3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
  4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
    869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
  5. ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

  6. もう一度コンストラクタを見てみよう。
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    mpBindings->Update( SID_ATTR_METRIC );
    の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
    よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
    Writerで用いる単位を設定画面からセンチメートルにしていた場合
    MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
    mpBindings->Update( SID_ATTR_METRIC );
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-14 追記: 原因の想像はついたけど、治し方が頭の中で固まらない

いや、わかってないのか。とりあえず調査の過程でこれでいいのか少なくとも一箇所自信がない場所がある。
https://opengrok.libreoffice.org/xref/core/sw/source/core/layout/pagechg.cxx?r=d36f7c5b#2359

1000 * 10^(-2) cm = 2362 * 10^(-2) pc Expected: 0< 1000 * 10^(-2) < 2100 * 10^(-2) cm - 50 * 10^(-2) cm
Actual: 2100 * 10^(-2) cm - 50 * 10^(-2) pc < 2362 * 10^(-2) → 2050 * 10^(-2) pc

2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

で、以下、やや推測込み。

  1. Writer起動
  2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
  3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
  4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
    869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
  5. ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

  6. もう一度コンストラクタを見てみよう。
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    mpBindings->Update( SID_ATTR_METRIC );
    の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
    よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
    Writerで用いる単位を設定画面からセンチメートルにしていた場合
    MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
    mpBindings->Update( SID_ATTR_METRIC );
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-14 追記: 原因の想像はついたけど、治し方が頭の中で固まらない

1000 * 10^(-2) cm = 2362 * 10^(-2) pc Expected: pc
Expected1:
0< 1000 * 10^(-2) < 2100 * 10^(-2) cm - 50 * 10^(-2) cm(Border)
Expected2: 0< 2362 * 10^(-2) pc - border < 4960.6 * 10^(-2) pc

Actual: 2100 * 10^(-2) cm pc - 50 * 10^(-2) pc < 2362 * 10^(-2) → 2050 * 10^(-2) pc

2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

で、以下、やや推測込み。

  1. Writer起動
  2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
  3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
  4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
    869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
  5. ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

  6. もう一度コンストラクタを見てみよう。
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    mpBindings->Update( SID_ATTR_METRIC );
    の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
    よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
    Writerで用いる単位を設定画面からセンチメートルにしていた場合
    MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
    mpBindings->Update( SID_ATTR_METRIC );
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-14 追記: 原因の想像はついたけど、治し方が頭の中で固まらない

1000 * 10^(-2) cm = 2362 * 10^(-2) pc
Expected1: 0< 0 cm< 1000 * 10^(-2) cm < 2100 * 10^(-2) cm - 50 * 10^(-2) cm(Border)
Expected2: 0< 0 pc < 2362 * 10^(-2) pc - border < 4960.6 * 10^(-2) pc
Actual: 2100 * 10^(-2) pc - 50 * 10^(-2) pc < 2362 * 10^(-2) → 2050 * 10^(-2) pc

2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

で、以下、やや推測込み。

  1. Writer起動
  2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
  3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
  4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
    869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
  5. ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

  6. もう一度コンストラクタを見てみよう。
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    mpBindings->Update( SID_ATTR_METRIC );
    の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
    よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
    Writerで用いる単位を設定画面からセンチメートルにしていた場合
    MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
    mpBindings->Update( SID_ATTR_METRIC );
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-14 追記: 原因の想像はついたけど、治し方が頭の中で固まらない

1000 * 10^(-2) cm = 2362 * 10^(-2) pc
Expected1: 0 cm< 1000 * 10^(-2) cm < 2100 * 10^(-2) cm - 50 * 10^(-2) cm(Border)
Expected2: 0 pc < 2362 * 10^(-2) pc - border < 4960.6 * 10^(-2) pc
Actual: 2100 * 10^(-2) pcpc - 50 * 10^(-2) pc < 2362 * 10^(-2) pc 2050 * 10^(-2) pc

2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

で、以下、やや推測込み。

  1. Writer起動
  2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
  3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
  4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
    869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
  5. ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

  6. もう一度コンストラクタを見てみよう。
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    mpBindings->Update( SID_ATTR_METRIC );
    の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
    よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
    Writerで用いる単位を設定画面からセンチメートルにしていた場合
    MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
    mpBindings->Update( SID_ATTR_METRIC );
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-14 追記: 原因の想像はついたけど、治し方が頭の中で固まらない

1000 * 10^(-2) cm = 2362 * 10^(-2) pc
Expected1: 0 cm< 1000 * 10^(-2) cm < 2100 * 10^(-2) cm - 50 * 10^(-2) cm(Border)
Expected2: 0 pc < 2362 * 10^(-2) pc - border < 4960.6 * 10^(-2) pc
Actual: 2100 * 10^(-2) pc - 50 * 10^(-2) pc < 2362 * 10^(-2) pc2050 * 10^(-2) pc


このときの「上限」は、長方形の左上の座標から、紙右端までの距離に依存するはず。一応念の為余白ゼロ、アンカーはページに、して紙の左上端から長方形を描いて実験した。

2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

で、以下、やや推測込み。

  1. Writer起動
  2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
  3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
  4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
    869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
  5. ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

  6. もう一度コンストラクタを見てみよう。
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    mpBindings->Update( SID_ATTR_METRIC );
    の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
    よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
    Writerで用いる単位を設定画面からセンチメートルにしていた場合
    MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
    mpBindings->Update( SID_ATTR_METRIC );
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-14 追記: 原因の想像はついたけど、治し方が頭の中で固まらない
1000 * 10^(-2) cm = 2362 * 10^(-2) pc
Expected1: 0 cm< 1000 * 10^(-2) cm < 2100 * 10^(-2) cm - 50 * 10^(-2) cm(Border)
Expected2: 0 pc < 2362 * 10^(-2) pc - border < 4960.6 * 10^(-2) pc
Actual: 2100 * 10^(-2) pc - 50 * 10^(-2) pc < 2362 * 10^(-2) pc2050 * 10^(-2) pc
このときの「上限」は、長方形の左上の座標から、紙右端までの距離に依存するはず。一応念の為余白ゼロ、アンカーはページに、して紙の左上端から長方形を描いて実験した。

2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

で、以下、やや推測込み。

  1. Writer起動
  2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
  3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
  4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
    869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
  5. ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

  6. もう一度コンストラクタを見てみよう。
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    mpBindings->Update( SID_ATTR_METRIC );
    の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
    よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
    Writerで用いる単位を設定画面からセンチメートルにしていた場合
    MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
    mpBindings->Update( SID_ATTR_METRIC );
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-14 追記: 原因の想像はついたけど、治し方が頭の中で固まらない
1000 * 10^(-2) cm = 2362 * 10^(-2) pc
Expected1: 0 cm< 1000 * 10^(-2) cm < 2100 * 10^(-2) cm - 50 * 10^(-2) cm(Border)
Expected2: 0 pc < 2362 * 10^(-2) pc - border < 4960.6 * 10^(-2) pc
Actual: 2100 * 10^(-2) pc - 50 * 10^(-2) pc < 2362 * 10^(-2) pc2050 * 10^(-2) pc
このときの「上限」は、長方形の左上の座標から、紙右端までの距離に依存するはず。一応念の為余白ゼロ、アンカーはページに、して紙の左上端から長方形を描いて実験した。

このときの「上限」は、長方形の左上の座標から、紙右端までの距離に依存するはず。一応念の為余白ゼロ、アンカーはページに、して紙の左上端から長方形を描いて実験した。

2018-04-18 追記:

再び、大まかに理解した。そのうち英語でバグレポ、場合によってはパッチも書くかもしれませんが、面倒なのでそれなりに遅れる予定。以下罫線等の話は無視する。

  • MetricFieldは最小値(0)、最大値(21)、現在値(10)を保持する。各数値の単位については継承元MetricFormatterのメンバ変数のmeUnit(cm)で統一されている。
  • void MetricFormatter::SetUnit( FieldUnit eNewUnit )は各数値をそのままに、「単位だけ」変更する。最小値は0 pc, 最大値は21pcだ こいつは表示文字列の生成等のためにReformatAll()を呼ぶ。
  • そこからの階層では当該文字列の数値(10.00)と文字列中の単位(cm)を取り出し、設定された単位への変換(23.62pc)を行い、新たな最小値、最大値の範囲内にあるか調べ、なかったときは、最小値または最大値にそれぞれ設定し直される。(21,pc,"21pc")。
  • こいつを使うvoid MetricField::SetUnit( FieldUnit nNewUnit )やvoid SetFieldUnit( MetricField& rField, FieldUnit eUnit, bool bAll)は最大値と最小値の問題には気づいたみたいで、21cmをtwipに変換した数値とかを変数に避けておいて、後でvoid MetricFormatter::SetMin( sal_Int64 nNewMin, FieldUnit eInUnit )とかで設定し直すんだけど、 現在値は再設定しない。最初の地点で単位変更前の現在値をtwipで取り出しておいて、あとにSetValueとかSetUserValueとかで代入してやれば治るかなあ?と思ってやってみたらとりあえずうまく動いてそうだ。あ、ちなみにSetMinやSetMaxもReformatAllを呼びます。

2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

で、以下、やや推測込み。

  1. Writer起動
  2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
  3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
  4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
    869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
  5. ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

  6. もう一度コンストラクタを見てみよう。
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    mpBindings->Update( SID_ATTR_METRIC );
    の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
    よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
    Writerで用いる単位を設定画面からセンチメートルにしていた場合
    MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
    mpBindings->Update( SID_ATTR_METRIC );
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-14 追記: 原因の想像はついたけど、治し方が頭の中で固まらない
1000 * 10^(-2) cm = 2362 * 10^(-2) pc
Expected1: 0 cm< 1000 * 10^(-2) cm < 2100 * 10^(-2) cm - 50 * 10^(-2) cm(Border)
Expected2: 0 pc < 2362 * 10^(-2) pc - border < 4960.6 * 10^(-2) pc
Actual: 2100 * 10^(-2) pc - 50 * 10^(-2) pc < 2362 * 10^(-2) pc2050 * 10^(-2) pc
このときの「上限」は、長方形の左上の座標から、紙右端までの距離に依存するはず。一応念の為余白ゼロ、アンカーはページに、して紙の左上端から長方形を描いて実験した。

2018-04-18 追記:

再び、大まかに理解した。そのうち英語でバグレポ、場合によってはパッチも書くかもしれませんが、面倒なのでそれなりに遅れる予定。以下罫線等の話は無視する。

  • MetricFieldは最小値(0)、最大値(21)、現在値(10)を保持する。各数値の単位については継承元MetricFormatterのメンバ変数のmeUnit(cm)で統一されている。
  • void MetricFormatter::SetUnit( FieldUnit eNewUnit )は各数値をそのままに、「単位だけ」変更する。最小値は0 pc, 最大値は21pcだ こいつは表示文字列の生成等のためにReformatAll()を呼ぶ。こいつは表示文字列の生成等のためにReformatAllからvoid MetricFormatter::Reformat()を呼ぶ。
  • そこからの階層では当該文字列の数値(10.00)と文字列中の単位(cm)を取り出し、設定された単位への変換(23.62pc)を行い、新たな最小値、最大値の範囲内にあるか調べ、なかったときは、最小値または最大値にそれぞれ設定し直される。(21,pc,"21pc")。
  • こいつを使うvoid MetricField::SetUnit( FieldUnit nNewUnit )やvoid SetFieldUnit( MetricField& rField, FieldUnit eUnit, bool bAll)は最大値と最小値の問題には気づいたみたいで、21cmをtwipに変換した数値とかを変数に避けておいて、後でvoid MetricFormatter::SetMin( sal_Int64 nNewMin, FieldUnit eInUnit )とかで設定し直すんだけど、 現在値は再設定しない。最初の地点で単位変更前の現在値をtwipで取り出しておいて、あとにSetValueとかSetUserValueとかで代入してやれば治るかなあ?と思ってやってみたらとりあえずうまく動いてそうだ。あ、ちなみにSetMinやSetMaxもReformatAllを呼びます。

2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

で、以下、やや推測込み。

  1. Writer起動
  2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
  3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
  4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
    869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
  5. ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

  6. もう一度コンストラクタを見てみよう。
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    mpBindings->Update( SID_ATTR_METRIC );
    の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
    よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
    Writerで用いる単位を設定画面からセンチメートルにしていた場合
    MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
    mpBindings->Update( SID_ATTR_METRIC );
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-14 追記: 原因の想像はついたけど、治し方が頭の中で固まらない
1000 * 10^(-2) cm = 2362 * 10^(-2) pc
Expected1: 0 cm< 1000 * 10^(-2) cm < 2100 * 10^(-2) cm - 50 * 10^(-2) cm(Border)
Expected2: 0 pc < 2362 * 10^(-2) pc - border < 4960.6 * 10^(-2) pc
Actual: 2100 * 10^(-2) pc - 50 * 10^(-2) pc < 2362 * 10^(-2) pc2050 * 10^(-2) pc
このときの「上限」は、長方形の左上の座標から、紙右端までの距離に依存するはず。一応念の為余白ゼロ、アンカーはページに、して紙の左上端から長方形を描いて実験した。

2018-04-18 追記:

再び、大まかに理解した。そのうち英語でバグレポ、場合によってはパッチも書くかもしれませんが、面倒なのでそれなりに遅れる予定。以下罫線等の話は無視する。

  • 一応念の為SetPosSizeMinMax()はSetFieldUnitよりも前で呼び出し、内部で使用されているSetMaxやSetMinは第二引数に単位を指定するようにした。不要かもしれない。
  • MetricFieldは最小値(0)、最大値(21)、現在値(10)を保持する。各数値の単位については継承元MetricFormatterのメンバ変数のmeUnit(cm)で統一されている。
  • void MetricFormatter::SetUnit( FieldUnit eNewUnit )は各数値をそのままに、「単位だけ」変更する。最小値は0 pc, 最大値は21pcだ こいつは表示文字列の生成等のためにReformatAllからvoid MetricFormatter::Reformat()を呼ぶ。
  • そこからの階層では当該文字列の数値(10.00)と文字列中の単位(cm)を取り出し、設定された単位への変換(23.62pc)を行い、新たな最小値、最大値の範囲内にあるか調べ、なかったときは、最小値または最大値にそれぞれ設定し直される。(21,pc,"21pc")。
  • こいつを使うvoid MetricField::SetUnit( FieldUnit nNewUnit )やvoid SetFieldUnit( MetricField& rField, FieldUnit eUnit, bool bAll)は最大値と最小値の問題には気づいたみたいで、21cmをtwipに変換した数値とかを変数に避けておいて、後でvoid MetricFormatter::SetMin( sal_Int64 nNewMin, FieldUnit eInUnit )とかで設定し直すんだけど、 現在値は再設定しない。最初の地点で単位変更前の現在値をtwipで取り出しておいて、あとにSetValueとかSetUserValueとかで代入してやれば治るかなあ?と思ってやってみたらとりあえずうまく動いてそうだ。あ、ちなみにSetMinやSetMaxもReformatAllを呼びます。

2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

で、以下、やや推測込み。

  1. Writer起動
  2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
  3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
  4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
    869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
  5. ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

  6. もう一度コンストラクタを見てみよう。
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    mpBindings->Update( SID_ATTR_METRIC );
    の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
    よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
    Writerで用いる単位を設定画面からセンチメートルにしていた場合
    MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
    mpBindings->Update( SID_ATTR_METRIC );
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-14 追記: 原因の想像はついたけど、治し方が頭の中で固まらない
1000 * 10^(-2) cm = 2362 * 10^(-2) pc
Expected1: 0 cm< 1000 * 10^(-2) cm < 2100 * 10^(-2) cm - 50 * 10^(-2) cm(Border)
Expected2: 0 pc < 2362 * 10^(-2) pc - border < 4960.6 * 10^(-2) pc
Actual: 2100 * 10^(-2) pc - 50 * 10^(-2) pc < 2362 * 10^(-2) pc2050 * 10^(-2) pc
このときの「上限」は、長方形の左上の座標から、紙右端までの距離に依存するはず。一応念の為余白ゼロ、アンカーはページに、して紙の左上端から長方形を描いて実験した。

2018-04-18 追記:

再び、大まかに理解した。そのうち英語でバグレポ、場合によってはパッチも書くかもしれませんが、面倒なのでそれなりに遅れる予定。以下罫線等の話は無視する。

  • 一応念の為SetPosSizeMinMax()はSetFieldUnitよりも前で呼び出し、内部で使用されているSetMaxやSetMinは第二引数に単位を指定するようにした。不要かもしれない。
  • MetricFieldは最小値(0)、最大値(21)、現在値(10)を保持する。各数値の単位については継承元MetricFormatterのメンバ変数のmeUnit(cm)で統一されている。
  • void MetricFormatter::SetUnit( FieldUnit eNewUnit )は各数値をそのままに、「単位だけ」変更する。最小値は0 pc, 最大値は21pcだ こいつは表示文字列の生成等のためにReformatAllからvoid MetricFormatter::Reformat()を呼ぶ。
  • そこからの階層では当該文字列の数値(10.00)と文字列中の単位(cm)を取り出し、設定された単位への変換(23.62pc)を行い、新たな最小値、最大値の範囲内にあるか調べ、なかったときは、最小値または最大値にそれぞれ設定し直される。(21,pc,"21pc")。
  • こいつを使うvoid MetricField::SetUnit( FieldUnit nNewUnit )やvoid SetFieldUnit( MetricField& rField, FieldUnit eUnit, bool bAll)は最大値と最小値の問題には気づいたみたいで、21cmをtwipに変換した数値とかを変数に避けておいて、後でvoid MetricFormatter::SetMin( sal_Int64 nNewMin, FieldUnit eInUnit )とかで設定し直すんだけど、 現在値は再設定しない。最初の地点で単位変更前の現在値をtwipで取り出しておいて、あとにSetValueとかSetUserValueとかで代入してやれば治るかなあ?と思ってやってみたらとりあえずうまく動いてそうだ。あ、ちなみにSetMinやSetMaxもReformatAllを呼びます。現在値は再設定しない。最初の地点で単位変更前の現在値をtwipで取り出しておいて、あとにSetValueとかSetUserValueとかで代入してやれば治るかなあ?と思ってやってみたらとりあえずうまく動いてそうだ。あ、ちなみにSetMinやSetMaxもReformatAllを呼びます。なおSetFieldUnitの第三引数はfalseである。関数の定義参照。

2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

で、以下、やや推測込み。

  1. Writer起動
  2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
  3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
  4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
    869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
  5. ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

  6. もう一度コンストラクタを見てみよう。
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    mpBindings->Update( SID_ATTR_METRIC );
    の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
    よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
    Writerで用いる単位を設定画面からセンチメートルにしていた場合
    MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
    mpBindings->Update( SID_ATTR_METRIC );
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。 となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

2018-04-20 追記: CMをINCHに変換するからずれるのであって、コンストラクタが内部数値の管理をCMで行うように変えれば単位同じだからずれないだろう、という策なので、コンストラクタ実行後にツール→オプションで内部管理単位をINCHに変更してOKしてから再びCMに戻すとズレます。このコード変更は「軽減するだけ」です。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-14 追記: 原因の想像はついたけど、治し方が頭の中で固まらない
1000 * 10^(-2) cm = 2362 * 10^(-2) pc
Expected1: 0 cm< 1000 * 10^(-2) cm < 2100 * 10^(-2) cm - 50 * 10^(-2) cm(Border)
Expected2: 0 pc < 2362 * 10^(-2) pc - border < 4960.6 * 10^(-2) pc
Actual: 2100 * 10^(-2) pc - 50 * 10^(-2) pc < 2362 * 10^(-2) pc2050 * 10^(-2) pc
このときの「上限」は、長方形の左上の座標から、紙右端までの距離に依存するはず。一応念の為余白ゼロ、アンカーはページに、して紙の左上端から長方形を描いて実験した。

2018-04-18 追記:

再び、大まかに理解した。そのうち英語でバグレポ、場合によってはパッチも書くかもしれませんが、面倒なのでそれなりに遅れる予定。以下罫線等の話は無視する。

  • 一応念の為SetPosSizeMinMax()はSetFieldUnitよりも前で呼び出し、内部で使用されているSetMaxやSetMinは第二引数に単位を指定するようにした。不要かもしれない。
  • MetricFieldは最小値(0)、最大値(21)、現在値(10)を保持する。各数値の単位については継承元MetricFormatterのメンバ変数のmeUnit(cm)で統一されている。
  • void MetricFormatter::SetUnit( FieldUnit eNewUnit )は各数値をそのままに、「単位だけ」変更する。最小値は0 pc, 最大値は21pcだ こいつは表示文字列の生成等のためにReformatAllからvoid MetricFormatter::Reformat()を呼ぶ。
  • そこからの階層では当該文字列の数値(10.00)と文字列中の単位(cm)を取り出し、設定された単位への変換(23.62pc)を行い、新たな最小値、最大値の範囲内にあるか調べ、なかったときは、最小値または最大値にそれぞれ設定し直される。(21,pc,"21pc")。
  • こいつを使うvoid MetricField::SetUnit( FieldUnit nNewUnit )やvoid SetFieldUnit( MetricField& rField, FieldUnit eUnit, bool bAll)は最大値と最小値の問題には気づいたみたいで、21cmをtwipに変換した数値とかを変数に避けておいて、後でvoid MetricFormatter::SetMin( sal_Int64 nNewMin, FieldUnit eInUnit )とかで設定し直すんだけど、 現在値は再設定しない。最初の地点で単位変更前の現在値をtwipで取り出しておいて、あとにSetValueとかSetUserValueとかで代入してやれば治るかなあ?と思ってやってみたらとりあえずうまく動いてそうだ。あ、ちなみにSetMinやSetMaxもReformatAllを呼びます。なおSetFieldUnitの第三引数はfalseである。関数の定義参照。

2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

で、以下、やや推測込み。

  1. Writer起動
  2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
  3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
  4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
    869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
  5. ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

  6. もう一度コンストラクタを見てみよう。
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    mpBindings->Update( SID_ATTR_METRIC );
    の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
    よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
    Writerで用いる単位を設定画面からセンチメートルにしていた場合
    MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
    mpBindings->Update( SID_ATTR_METRIC );
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

2018-04-20 追記: CMをINCHに変換するからずれるのであって、コンストラクタが内部数値の管理をCMで行うように変えれば単位同じだからずれないだろう、という策なので、コンストラクタ実行後にツール→オプションで内部管理単位をINCHに変更してOKしてから再びCMに戻すとズレます。cmをinchに変換するからずれるのであって、コンストラクタがPozSizePropertyPanelの数値の内部管理meDlgUnit(後にSetFieldUnitでMetricFieldの単位meUnitにも利用される)をcmで行うように変えれば単位同じだからずれないだろう、という策なので、コンストラクタ実行後にツール→オプションで内部管理単位をINCHに変更してOKしてから再びCMに戻すとズレます。このコード変更は「軽減するだけ」です。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-14 追記: 原因の想像はついたけど、治し方が頭の中で固まらない
1000 * 10^(-2) cm = 2362 * 10^(-2) pc
Expected1: 0 cm< 1000 * 10^(-2) cm < 2100 * 10^(-2) cm - 50 * 10^(-2) cm(Border)
Expected2: 0 pc < 2362 * 10^(-2) pc - border < 4960.6 * 10^(-2) pc
Actual: 2100 * 10^(-2) pc - 50 * 10^(-2) pc < 2362 * 10^(-2) pc2050 * 10^(-2) pc
このときの「上限」は、長方形の左上の座標から、紙右端までの距離に依存するはず。一応念の為余白ゼロ、アンカーはページに、して紙の左上端から長方形を描いて実験した。

2018-04-18 追記:

再び、大まかに理解した。そのうち英語でバグレポ、場合によってはパッチも書くかもしれませんが、面倒なのでそれなりに遅れる予定。以下罫線等の話は無視する。

  • 一応念の為SetPosSizeMinMax()はSetFieldUnitよりも前で呼び出し、内部で使用されているSetMaxやSetMinは第二引数に単位を指定するようにした。不要かもしれない。
  • MetricFieldは最小値(0)、最大値(21)、現在値(10)を保持する。各数値の単位については継承元MetricFormatterのメンバ変数のmeUnit(cm)で統一されている。
  • void MetricFormatter::SetUnit( FieldUnit eNewUnit )は各数値をそのままに、「単位だけ」変更する。最小値は0 pc, 最大値は21pcだ こいつは表示文字列の生成等のためにReformatAllからvoid MetricFormatter::Reformat()を呼ぶ。
  • そこからの階層では当該文字列の数値(10.00)と文字列中の単位(cm)を取り出し、設定された単位への変換(23.62pc)を行い、新たな最小値、最大値の範囲内にあるか調べ、なかったときは、最小値または最大値にそれぞれ設定し直される。(21,pc,"21pc")。
  • こいつを使うvoid MetricField::SetUnit( FieldUnit nNewUnit )やvoid SetFieldUnit( MetricField& rField, FieldUnit eUnit, bool bAll)は最大値と最小値の問題には気づいたみたいで、21cmをtwipに変換した数値とかを変数に避けておいて、後でvoid MetricFormatter::SetMin( sal_Int64 nNewMin, FieldUnit eInUnit )とかで設定し直すんだけど、 現在値は再設定しない。最初の地点で単位変更前の現在値をtwipで取り出しておいて、あとにSetValueとかSetUserValueとかで代入してやれば治るかなあ?と思ってやってみたらとりあえずうまく動いてそうだ。あ、ちなみにSetMinやSetMaxもReformatAllを呼びます。なおSetFieldUnitの第三引数はfalseである。関数の定義参照。

2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

で、以下、やや推測込み。

  1. Writer起動
  2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
  3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
  4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
    869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
  5. ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

  6. もう一度コンストラクタを見てみよう。
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    mpBindings->Update( SID_ATTR_METRIC );
    の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
    よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
    Writerで用いる単位を設定画面からセンチメートルにしていた場合
    MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
    mpBindings->Update( SID_ATTR_METRIC );
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

2018-04-20 追記: cmをinchに変換するからずれるのであって、コンストラクタがPozSizePropertyPanelの数値の内部管理meDlgUnit(後にSetFieldUnitでMetricFieldの単位meUnitにも利用される)をcmで行うように変えれば単位同じだからずれないだろう、という策なので、コンストラクタ実行後にツール→オプションで内部管理単位をINCHに変更してOKしてから再びCMに戻すとズレます。このコード変更は「軽減するだけ」です。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-14 追記: 原因の想像はついたけど、治し方が頭の中で固まらない
1000 * 10^(-2) cm = 2362 * 10^(-2) pc
Expected1: 0 cm< 1000 * 10^(-2) cm < 2100 * 10^(-2) cm - 50 * 10^(-2) cm(Border)
Expected2: 0 pc < 2362 * 10^(-2) pc - border < 4960.6 * 10^(-2) pc
Actual: 2100 * 10^(-2) pc - 50 * 10^(-2) pc < 2362 * 10^(-2) pc2050 * 10^(-2) pc
このときの「上限」は、長方形の左上の座標から、紙右端までの距離に依存するはず。一応念の為余白ゼロ、アンカーはページに、して紙の左上端から長方形を描いて実験した。

2018-04-18 追記:

再び、大まかに理解した。そのうち英語でバグレポ、場合によってはパッチも書くかもしれませんが、面倒なのでそれなりに遅れる予定。以下罫線等の話は無視する。

  • 一応念の為SetPosSizeMinMax()はSetFieldUnitよりも前で呼び出し、内部で使用されているSetMaxやSetMinは第二引数に単位を指定するようにした。不要かもしれない。
  • MetricFieldは最小値(0)、最大値(21)、現在値(10)を保持する。各数値の単位については継承元MetricFormatterのメンバ変数のmeUnit(cm)で統一されている。
  • void MetricFormatter::SetUnit( FieldUnit eNewUnit )は各数値をそのままに、「単位だけ」変更する。最小値は0 pc, 最大値は21pcだ こいつは表示文字列の生成等のためにReformatAllからvoid MetricFormatter::Reformat()を呼ぶ。
  • そこからの階層では当該文字列の数値(10.00)と文字列中の単位(cm)を取り出し、設定された単位への変換(23.62pc)を行い、新たな最小値、最大値の範囲内にあるか調べ、なかったときは、最小値または最大値にそれぞれ設定し直される。(21,pc,"21pc")。
  • こいつを使うvoid MetricField::SetUnit( FieldUnit nNewUnit )やvoid SetFieldUnit( MetricField& rField, FieldUnit eUnit, bool bAll)は最大値と最小値の問題には気づいたみたいで、21cmをtwipに変換した数値とかを変数に避けておいて、後でvoid MetricFormatter::SetMin( sal_Int64 nNewMin, FieldUnit eInUnit )とかで設定し直すんだけど、 現在値は再設定しない。最初の地点で単位変更前の現在値をtwipで取り出しておいて、あとにSetValueとかSetUserValueとかで代入してやれば治るかなあ?と思ってやってみたらとりあえずうまく動いてそうだ。あ、ちなみにSetMinやSetMaxもReformatAllを呼びます。なおSetFieldUnitの第三引数はfalseである。関数の定義参照。

https://bugs.documentfoundation.org/show_bug.cgi?id=99711

2018-04-07 ほぼ全面改訂

自信なし。回答欄使うけど、回答にあらず。強い違和感あるけど仕様…かなぁ?ズレが見られるのはサイドバーのパネルだけでコンテキストメニューから呼び出すダイアログは問題ないので仕様ではない

通りすがり氏の実装に関する推測は正しい。ログを取ってみたら394とそこから10.01が出てきていた。(計算の一部数値をhimajin100000側で書き換えてます)

多分、内部での計算は全てインチで行い、表示時にcmに変換するのでしょう。 問題は、内部計算毎に小数点3位で四捨五入して小数点2桁にしているのではないのでしょうか。 10cm=3.93700787401575in→3.94in=3.94x2.54=10.0076 →10.01 20cm=7.8740157480315in→7.87in=7.87x2.54=19.9898 → 19.99

で、以下、やや推測込み。

  1. Writer起動
  2. Writerでサイドバーを表示する。この段階では「位置とサイズ」セクションはない。
  3. 長方形を図形描画すると、サイドバーのパネル表示に必要になったときにPosSizePropertyPanelのコンストラクタが走るようで、初期値の設定に関わる。
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#49
  4. mpBindings->Update( SID_ATTR_METRIC );が実行されたとき、MetricStateが走り https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#724
    https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#860
    869行目でメンバ変数meDlgUnitに代入がなされる。このメンバ変数に代入が行われるのは、ソースコード上ここだけである。
  5. ところで、 SetFieldUnitは、指定されたコントロールの内部で保持するときの単位を指定している。 https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/possize/PosSizePropertyPanel.cxx?r=44d5188b#531

  6. もう一度コンストラクタを見てみよう。
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    mpBindings->Update( SID_ATTR_METRIC );
    の順であるから、SID_ATTR_TRANSFORM_WIDTHの段階では、まだSID_ATTR_METRIC用の処理は走ってない。
    よって、内部設定用に使われる単位はmeDlgUnitの初期値のFUNIT_INCHである。
    Writerで用いる単位を設定画面からセンチメートルにしていた場合
    MetricStateで呼ばれるGetCurrentUnitが返す値はFUNIT_CMだったようなので、
    mpBindings->Update( SID_ATTR_METRIC );
    mpBindings->Update( SID_ATTR_TRANSFORM_WIDTH );
    mpBindings->Update( SID_ATTR_TRANSFORM_HEIGHT );
    mpBindings->Update( SID_ATTR_TRANSFORM_PROTECT_SIZE );
    となっていれば、0.01cmのズレは発生しないように思う。少なくとも手元のビルドでは問題ない。

2018-04-20 追記: cmをinchに変換するからずれるのであって、コンストラクタがPozSizePropertyPanelの数値の内部管理meDlgUnit(後にSetFieldUnitでMetricFieldの単位meUnitにも利用される)をcmで行うように変えれば単位同じだからずれないだろう、という策なので、コンストラクタ実行後にツール→オプションで内部管理単位をINCHに変更してOKしてから再びCMに戻すとズレます。このコード変更は「軽減するだけ」です。

ここからコード上未調査・未解決。話はここで終わらないのだ。どのタイミングでコンストラクタが走っているのか、という問題だ。

問題が起きているバージョンで話を進める。なお、以下の項目の手順は互いに独立である。

  1. 長方形一つを描画し、サイドバーから幅を10.00cmにし、ツールバーから矢印を選択、長方形以外のところをクリックすると、当該パネルがなくなり、もう一度長方形を選択したとき、コンストラクタが走ってずれる。
  2. 長方形二つを描画し、一方の長方形を選択している状態でサイドバーから幅"10.00cm"を入力する。 他方の長方形を選択してから、元の長方形を選択する。このときはずれない。
  3. 長方形一つを描画し、サイドバーから幅"10.00cm"を入力する。サイドバー横のタブからサイドバーの内容を一旦ナビゲータに切り替えてからプロパティに戻す。このときもずれない。
  4. 長方形一つを描画し、サイドバーから幅"10.00cm",高さ"10.00cm"を入力する。ここで[Tools]-[Options]-[LibreOfficeDev]-[LibreOffice Writer]のMesurementUnitをPicaにし、OKを押してダイアログを閉じる。再び設定画面をMeasurement UnitをCentimeterに戻し、長方形を選択する。このときサイドバーに表示されている数値がおかしくなる。ただし、一旦長方形以外のところをクリックしてから長方形をクリックすると10.01cmに戻る。

2018-04-14 追記: 原因の想像はついたけど、治し方が頭の中で固まらない
1000 * 10^(-2) cm = 2362 * 10^(-2) pc
Expected1: 0 cm< 1000 * 10^(-2) cm < 2100 * 10^(-2) cm - 50 * 10^(-2) cm(Border)
Expected2: 0 pc < 2362 * 10^(-2) pc - border < 4960.6 * 10^(-2) pc
Actual: 2100 * 10^(-2) pc - 50 * 10^(-2) pc < 2362 * 10^(-2) pc2050 * 10^(-2) pc
このときの「上限」は、長方形の左上の座標から、紙右端までの距離に依存するはず。一応念の為余白ゼロ、アンカーはページに、して紙の左上端から長方形を描いて実験した。

2018-04-18 追記:

再び、大まかに理解した。そのうち英語でバグレポ、場合によってはパッチも書くかもしれませんが、面倒なのでそれなりに遅れる予定。以下罫線等の話は無視する。

  • 一応念の為SetPosSizeMinMax()はSetFieldUnitよりも前で呼び出し、内部で使用されているSetMaxやSetMinは第二引数に単位を指定するようにした。不要かもしれない。
  • MetricFieldは最小値(0)、最大値(21)、現在値(10)を保持する。各数値の単位については継承元MetricFormatterのメンバ変数のmeUnit(cm)で統一されている。
  • void MetricFormatter::SetUnit( FieldUnit eNewUnit )は各数値をそのままに、「単位だけ」変更する。最小値は0 pc, 最大値は21pcだ こいつは表示文字列の生成等のためにReformatAllからvoid MetricFormatter::Reformat()を呼ぶ。
  • そこからの階層では当該文字列の数値(10.00)と文字列中の単位(cm)を取り出し、設定された単位への変換(23.62pc)を行い、新たな最小値、最大値の範囲内にあるか調べ、なかったときは、最小値または最大値にそれぞれ設定し直される。(21,pc,"21pc")。
  • こいつを使うvoid MetricField::SetUnit( FieldUnit nNewUnit )やvoid SetFieldUnit( MetricField& rField, FieldUnit eUnit, bool bAll)は最大値と最小値の問題には気づいたみたいで、21cmをtwipに変換した数値とかを変数に避けておいて、後でvoid MetricFormatter::SetMin( sal_Int64 nNewMin, FieldUnit eInUnit )とかで設定し直すんだけど、 現在値は再設定しない。最初の地点で単位変更前の現在値をtwipで取り出しておいて、あとにSetValueとかSetUserValueとかで代入してやれば治るかなあ?と思ってやってみたらとりあえずうまく動いてそうだ。あ、ちなみにSetMinやSetMaxもReformatAllを呼びます。なおSetFieldUnitの第三引数はfalseである。関数の定義参照。

https://bugs.documentfoundation.org/show_bug.cgi?id=99711

https://bugs.documentfoundation.org/show_bug.cgi?id=99711
https://bugs.documentfoundation.org/show_bug.cgi?id=118837