帳票のレイアウト設計時に気にする箇所

利用シーン

注文の明細とか

A4用紙を8等分して、それぞれ切って、それを見ながら作業に使うとか

現場と議論しながら細かい調整が必要

いつ使うのか、誰が使うのか

年配の人が使う場合はフォントを大きくする、太くする、なども出てくる

レイアウト上の制約が多い

通常のwebと大きく異なる

物理的な用紙のサイズの制約を受ける

幅が固定

縦も伸びればよいというものでもない

1枚に収まらないといけない、1枚の4等分の高さに収まらないといけないといった要件も多い

改行して良い部分とダメな部分がある

変な箇所で改行されていると誤読する

e.g.

code:ok

10.45m x 20.35m

code:ng

10.45m x 20

.35m

文字数が多い場合にどうするか

収まるまでfont-sizeを小さくする

部分的にfont-sizeを小さくする

e.g. 長い名前の場合、名字だけ大きく、下の名前は小さくする

改行を許す

末尾を省略する

etc.

ページを跨ぐときの扱い

帳票内の項目数が多くて1枚の紙には収まりきらない時はページを跨ぐ

跨ぐ場合のheader、footerの扱い

e.g. ページを跨いだときも常にheaderを表示する

e.g. ページを跨いだときは、headerを表示しない

「このブロックはページで途切れてはいけない」のような項目がないか

コンテンツの種類によって、ページを跨いで良い箇所と、行けない箇所とがありうる

e.g. テーブルの1行は途中で途切れてほしくない

e.g. この小テーブルは一纏まりで見たいので、途中で途切れてほしくない

ページ番号

紙がバラバラになったときにわからなくならないようにページ番号を表示する

ページ番号の振り方も工夫が必要な場合がある

例えば、Orderを3件を6ページに表示する際に、

など

実際に印刷して確認する

プレビューと実際の印刷時でズレがあるかもしれない

プレビューでは視えている細いborderが、印刷時はかすれているかもしれない

現場の要望が入りがち

実際に運用してみてから、「やっぱこうしてほしい」という修正入りがち

新たにこの情報を出して欲しい

文字を太くして欲しい

etc.

プロトタイピングの段階で、それを見て作業を行う、などをやっていなかったからか？

デグレを防ぐことが難しい

上記のような制約もあって、かなり容易にレイアウトが壊れる

最大文字数を意識する

要素によっては最大文字数が事前に決まるものがある

e.g. 10.45m x 10.45m

決まらないものもある

e.g. 人名、住所

改行するのか、省略するのか、font-sizeを変えるのか、対応しておく必要がる

文字数で縛れない

フォントサイズの違いもあるので

grid layoutと微妙に相性が悪いところもある

3つの要素が横に並ぶ時に、良い感じに幅の補正が入る

逆に言えば、その3つの組み合わせで、はみ出るかどうかが決まるので、テストすべきパターンの数が増える

3カラムの幅が決まっている方がテストすべきパターンは減る

まあ、これのおかげでpassするケースが増えてるのだけど

Property Based Testingをする

個別の値ごとに取りうる範囲を決めて、ランダムに生成する

いや、ランダムにやる必要性は薄そう

最大長のやつを論理的に組み合わせて確認できる範囲だろう

修正時に、前後でどこが変わったのか記録したい

ロジックなら、これがテストで残しやすい

修正前の実装でfailし、修正後の実装でpassするようなtestを書けば良い

ビジュアルではこれが残して、自動で確認する、というのがやりづらい

VRTでスクショを残すだけじゃこれは防げない

用紙サイズ

枠線の太さ

font

種類、太さ、見やすさ

font-size

余白の大きさ