Implement "New Report Type: Section Report" · Issue #12 · thinreports/thinreports · GitHub
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement "New Report Type: Section Report" #12

Closed
hidakatsuya opened this issue Oct 6, 2020 · 8 comments
Closed

Implement "New Report Type: Section Report" #12

hidakatsuya opened this issue Oct 6, 2020 · 8 comments

Comments

@hidakatsuya
Copy link
Member

hidakatsuya commented Oct 6, 2020

Summary

We have implemented the section-report format proposed at the Issue: New Report Type: SectionReport, and created pull requests for the generator and the editor respectively.

We are actually using this implementation in our products and would like to provide this to the Thinreports community.

However, our current implementation is incomplete and still have some issues to discuss. We would like to discuss how to solve those issues, how to proceed with the development, and work with the community towards the release of the section-report format.

Specification

The specifications of our section report implementation is based on the Issue: New Report Type: SectionReport.

Issues

However, the current implementation contains specifications that differ from the Issue: New Report Type: SectionReport, features that we added independently, and specifications that we have not been implemented. There are also some known issues. See the Implementation Status section of each pull request for details.

Examples

We have created some examples of the section-report format features as feature tests for the generator. Each example includes a description of the specifications, a Ruby code, a template file, and an output PDF file.

Note

Our blog post about the section-report format may be helpful:

Getting Started

Installing

See the Getting Started section of each pull request.

Hello World

First, create a template.

detailed instructions for creating a template

Launch the editor applicaiton.

img1

Delete the header and footer sections, which are unnecessary in this example.
Click the section region to select, and click 削除 (Delete) in the 編集 (Edit) menu.

img2

Specify the properties of the detail section.
Click the detail section region. In the right property pane, input hello_world as the ID attribute. And enter 100 as the 高さ (height) attribute.

img3

Put a text-block on the detail section.
Select the text-block tool (the red circle in the figure) in the toolbar. And drag and drop in the detail section to create a text-block at the region. You can leave the text-block properties as the default values.

img4

The template is now complete.

This is a simple template which has a detail section whose ID is hello_world. The detail section includes a text-block whose ID is text.

img6

Create a dirctory named hello_world in an arbitrary location, and save the template as template.tlf in the hello_world directory.

Then, create generate.rb in the hello_world directory, and write the following code:

require 'thinreports'

report_params = {
  type: :section,
  layout_file: 'template.tlf',
  params: {
    groups: [
      {
        details: [
          {
            id: 'hello_world',
            items: {
              text: 'Hello World'
            }
          },
          {
            id: 'hello_world',
            items: {
              text: 'Hello Thinreports'
            }
          }
        ]
      }
    ]
  }
}

Thinreports.generate(report_params, filename: 'hello.pdf')

Execute this, and hello.pdf is generated in the hello_world directory.

$ cd /path/to/hello_world
$ ruby generate.rb

hello.pdf:
hello.pdf

Future Development

There are still some issues and unimplemented specifications left. But the section-report format is a huge specification and it would be difficult to complete this on our own. Not only are there insufficient development resources, but there is also a need for discussion to make the specifications optimal for Thinreports.

Based on our implementation, we would like to discuss and develop it gradually with the community.

Specifically, we propose the following development approach:

  1. Merge the current code into the master branch basically as it is.
  2. In issues, discuss and determine specifications and architectures that need to be discussed.
  3. Document the specifications as needed.
  4. Create tasks as issues based on the determined specifications.
  5. Develop based on the tasks.

In order for many developers to participate, we need a foundation such as the specifications and the tasks. It may take some time to put it in place, but we think it is necessary for sustainable development.

It's also a good idea to create small tasks and use labels like good for first issue to make it easier for new developers to join, and use the GitHub Project to clarify the roadmap and development status.

@hidakatsuya
Copy link
Member Author

hidakatsuya commented Oct 17, 2020

@maeda-m Let me hear what you think. If you have any questions, please ask.

意見を聞かせてくだされ。もしわからんことがあれば聞いてください。

@hidakatsuya
Copy link
Member Author

なお、議論をして一定の形にすることが目的なので、日本語など英語以外でのコメントも遠慮なくどうぞ。

@hidakatsuya
Copy link
Member Author

下記記事で SectionReport で何ができるのかについて簡単に説明されています (in japanese)。
https://tech.misoca.jp/entry/2020/10/13/120500

@maeda-m
Copy link
Member

maeda-m commented Oct 30, 2020

偉大な提案で、私にとって学びが多くありました。ありがとうございます。
この提案に対して否定的な意見はありません。全面的に賛同し、支持します。

以下、思ったことを挙げます。

  • "Examples" が分かりやすくかつ丁寧な内容で、私の理解を早める手助けをしてくれました。
  • "Future Development" で言及されていましたが、持続可能な開発を目指すためには多くの準備を必要とすると私も思います。
    • Editor の理解を深めるために、Vue.js や TypeScript のドキュメントを参照しました。
      • Linter が導入済みであるため、安心感がありますね。
  • Editor
    • オリジナルフォーマットのフォルダは basic_report で無難かなと思いました。
    • 複数選択などの状態管理は、慎重に議論する必要がありそうですね。
      • 従来の実装とは比較にならないほど洗練されていますが、それでも扱いが難しいと考えています。
    • Text の高さ計算は、 WebAssembly など別のアプローチも必要なのかなと思いました(これは思い付きです)。
  • Generator
    • StackView や自動収縮は非常に便利で様々な場面で重宝される機能だと思いました。

以上です。 😄

@hidakatsuya
Copy link
Member Author

hidakatsuya commented Nov 7, 2020

@maeda-m
コメントありがとう。

  • 複数選択などの状態管理は、慎重に議論する必要がありそうですね。

そうですね。複数選択だけでなく、editor の機能や仕様については、既存の editor を踏襲するのではなく、改めて取捨選択したいと思っています。

  • Text の高さ計算は、 WebAssembly など別のアプローチも必要なのかなと思いました(これは思い付きです)。

WebAssembly がどのようなものか詳しくありませんが、提案した editor でテキストの高さの計算方法を変更した最大の理由は、既存の算出方法(下記)では、OS やディスプレイ解像度など、利用環境によって算出したテキストの高さが異なることです。

line-height-ratio = (height calculated from the drawn text) * line-height

その一つの解として、フォントサイズによるシンプルな計算方法を採用しました。

line-height-ratio = font-size * line-height

提案した editor は、私達のプロダクトで実際に使っていますが、現時点ではこの計算方法で問題は発生していません。もちろん、この高さは正確なものでなく、editor 上の高さと生成されたPDFの高さと一致しない可能性があることは認めますが、多くの場合そこまでの厳密さは必要ではないと考えています。

将来、WebAssembly など、editor 上でより厳密で環境に依存しない算出方法を見つけたら、それを採用することを試みても良いと考えています。

さて、

Future Development

の提案についてはどう考えていますか?この提案に異論が無ければ、editor と generator の pullrequest を取り込み、開発を進めていきたいと思っています。

その開発の進め方については、提案に書いてある通りですが、取り込んだ上で、改めて別の issue で議論したいと思っています。

@maeda-m
Copy link
Member

maeda-m commented Nov 9, 2020

@hidakatsuya

既存の editor を踏襲するのではなく、改めて取捨選択したいと思っています。

同意見です。

提案した editor は、私達のプロダクトで実際に使っていますが、現時点ではこの計算方法で問題は発生していません。

そうなのですね。自動収縮などの振舞いが前提となると、厳密さは必要ないのかもしれませんね。

この提案に異論が無ければ、editor と generator の pullrequest を取り込み、開発を進めていきたいと思っています。
その開発の進め方については、提案に書いてある通りですが、取り込んだ上で、改めて別の issue で議論したいと思っています

はい。異論はありません。

@hidakatsuya
Copy link
Member Author

@maeda-m
では、今週末に editor と generator をマージしますね。

@hidakatsuya
Copy link
Member Author

hidakatsuya commented Nov 29, 2020

Editor と Generator の上記 pull request をマージしました。どちらも CI がパスしていることは確認したので、この issue はクローズしますね。

なお、この後の開発の進め方などは、一旦 #7 のコメントで話しましょうか。


The Editor and Generator pull requests have been merged. Now that I've confirmed that they both pass CI, I'll close this issue.

Let's talk about the next steps of development in the comments of #7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants