Ver6.2.4のCALC OSはWindows10を使用しています。
書式‐印刷範囲より繰り返す行を設定したとき、繰り返す行に指定した行の直下の行に設定された罫線が繰り返しの対象となってしまいます。
つまり、繰り返す行を「$1」と設定したときに、印刷プレビューで確認すると、設定した1行目だけでなく、意図しない2行目に設定した罫線も繰り返しの対象となります。
繰り返されるのは、罫線のみで背景色などは問題ないようです。
回避できるものでしょうか。
よろしくお願いします。
再現したが、まだ原因は不明。
https://opengrok.libreoffice.org/xref/core/sc/source/ui/view/printfun.cxx?r=c18e2ea2#1597
https://opengrok.libreoffice.org/xref/core/sc/source/ui/view/printfun.cxx?r=c18e2ea2#2272
https://opengrok.libreoffice.org/xref/core/sc/source/ui/view/printfun.cxx?r=c18e2ea2#2284
ココらへんを追うとわかるのかなーと漠然と思う。
この行の意図がわかればなぁ…
https://opengrok.libreoffice.org/xref/core/sc/source/core/data/fillinfo.cxx?r=d4dd0732#400
(以下、解決策ではありません。エンドユーザ向けではなく開発者向け参考情報です。)
コードを読み飛ばせるようにして問題を簡単にするために、以下を仮定する。
- いかなるセルも結合されていない
- いかなるセルも条件付き書式を持たない
- いかなるセルも非表示になっていない
連続するセルが同一の書式を持っていた場合に配列であるpThisAttrArr->mvDataは、同じ書式を持つ連続したセル範囲の終端の行を0-baseで記録している。本件の最初の列のデータの場合、0から70までの全71行につき、0番目の行、1番めの行、2番めの行はそれぞれ別の書式が与えられ、3行目以降はすべて同じ書式であるからソースコードの485行目から598行目までのループのnThisRowの値は、それぞれ、0,1,2,70となる。このデータの持ち方をしているのは多分メモリの節約であろうが、実際に使うときは3行から70行までのデータを展開している。
ところで、どうも、pRowInfoについては、さっきまでのstd::unique_ptr pAttrArrayと異なり、-1から71行までの72行を想定して初期化しているようだ。 後述のnYExtraの内容も参照。内容は標準的な書式や行の高さ。番兵のつもりか？
ここで使われているnYExtraは大本をたどると1,2,3で、nRepeatEndRow+1である。今回の事例において、エンドユーザの期待は、最初の行つまり0行目のみを繰り返すことであるからnRepeatStartRowとnRepeatEndRowは0である。
nYExtraは1である。ここで、fillinfo.cxxの595行目、および593行目を考える。繰り返し行として0行目をやっている地点でnCurRowは0であり、593行目通過後は1になり、nCurRow <= nYExtraはtrueであるから、485行目から595行目までのループは1行分余計に回ってしまう！
なので、例えば、
401行目の直後にnYExtra–;を仕込んでみるとか、595行目をnCurRow < nYExtraにしてみるとか(等号を外した)、あるいは条件としてnCurRow <= rRow2 にしてみるとうまくいくようだった。一応、番兵のため195行目の条件でこのSCROW & rYExtraは使われているので、単純に、SCROW nYExtra = nRow2;という初期化をしたりするのは駄目。また、少なくともScPrintFunc::PrintAreaのせいで、
PrintArea( nX1,nRepeatStartRow, nX2,nRepeatEndRow-1, nDataX,nRepStartY,!bDoRepCol, true, true, false );みたいな手も一応検討したけどダメそうだった。
コード的な意味は理解していないものの、7.3.0.3で再現しないことを確認しました。
2 Likes
同じく、手元でも7.2.5までは再現、7.3.0以降は不再現のようです。Win 10。
（この件…前にも見たことある気がするな…。どこで知ったんだったか…。）
1 Like