Minoru Maeda

@hidakatsuya おぉー。情報共有や相談の "場" があると助かります。 都度 issue を作成するより軽量で良いと思います。 > 早速共有ですが、v1.0.0-dev.first-build に「section editor のライセンスを MIT-LICENSE にする」を追加しました。 そうですね。早いうちに同意を得たり、必要であればコントリビュートガイドの見直し（ライセンスが異なることを追記する？）が必要なのかもしれませんね。 > 「section editor の名前を付けて保存」カードを v1.0.0 から外し v1.0.0 or later に移動しました。 なるほど。OSの機能でファイル名を変更すれば良いですし、なくてもストレスになりにくいですね。 ちなみに私も、v1.0.0-dev.first-build に「Windows 環境でのパッケージビルドエラーを解決する」を追加しました。 まずはローカルでビルドが成功するように環境を変えて試してみます。...

@hidakatsuya > 可能な範囲で感想を聞かせて欲しいです。 > これらの仕様案についての意見も聞いてみたい。 1年以上前に custom-font ブランチを某製品で使用しました。 PostScript 名など幾つか注意する（丁寧に確認する）点はありましたが、 カスタムフォントを使用したPDF生成を実現できました。ありがとうございました。 感想としては、私が使用するには必要十分でしたが、カスタムフォントの登録方法は、別のアプローチの方が好まれるかもしれません。 例えば、カスタムフォントの登録をレイアウト単位ではなく、Editorの環境設定として保持する等です。 また、OS によっては PostScript 名が異なる場合があったので（フォントによるかもしれない）、 Editor 上のカスタムフォント登録は厳密に検査せずに単純なフォント名指定として扱い、 Generator の register_font で指定するフォント名と一致すれば良い等の考えにしたほうがいいかもしれません。 これは、私が Editor 上のテキスト位置はあくまでも目安で、最終的な調整は生成されたPDFを確認しながらすれば良いと考えているためです。

@hidakatsuya > 一方で、Editor 上で出力結果を確認できることが Thinreports の強みの一つだと考えているので、最終的にフォントを再現できることを見据えた仕様にしておきたいと思います。 ですよね。テキスト位置と罫線とかの位置合わせが稀にあるので、フォントを再現できたら嬉しいと思います。 > 具体的に、カスタムフォントの登録方法としてどんなものをイメージしてます？ コメントを書いている途中で気づいたのですが、 > 例えば、カスタムフォントの登録をレイアウト単位ではなく、Editorの環境設定として保持する等です。 はズレた意見で、当時、私が抱えていた困りごとを解決する手段ではなさそうです。ですので忘れてください。 --- 以下、書いていたコメント。 機能概要 > カスタムフォント登録の流れ にあるレポート設定の図の様なものが、 Editor の環境設定にあるのをイメージしています。 これは、某製品開発の事情でレイアウト単位のカスタムフォント登録だと煩雑な場合があったためです。 少し曖昧な表現になりますが、複数人でのわりかし大量の帳票レイアウトを一斉に作成する環境において、フォント指定ミスの有無を確認・修正する場合です。 この時、困ったことはレイアウト内の静的／動的テキストのフォントが確認しにくいことでした。 ※ ドキュメントエクスポート機能はありますが、そもそもフォント情報は出力していないので活用していませんでした。 以上。

バーコードオブジェクトの描画方法とカスタマーバーコードのコードを追記しました。

Thank you for the report. Maybe this is not a bug in DefaultCustomQuery. I think that it is a coding mistake of other plug-ins. An error occurs if the following...

Thank you for the report. Released [version 1.5.0](https://github.com/hidakatsuya/redmine_default_custom_query/releases/tag/1.5.0) !

:memo: [ふりかえり・計画ミーティング2023年01月11日](https://github.com/fjordllc/bootcamp/wiki/%E3%81%B5%E3%82%8A%E3%81%8B%E3%81%88%E3%82%8A%E3%83%BB%E8%A8%88%E7%94%BB%E3%83%9F%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B02023%E5%B9%B401%E6%9C%8811%E6%97%A5) よりメモ react に変える vue コンポーネントを使用している vue コンポーネントがあるため、この議題では react コンポーネントの新規作成までとする。 現状の vue コンポーネントには何もしない。

#6039 が本日リリースされました。 コンポーネントファイルの追加のみのため Close します🎉

📝 [ふりかえり・計画ミーティング2023年01月25日](https://github.com/fjordllc/bootcamp/wiki/%E3%81%B5%E3%82%8A%E3%81%8B%E3%81%88%E3%82%8A%E3%83%BB%E8%A8%88%E7%94%BB%E3%83%9F%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B02023%E5%B9%B401%E6%9C%8825%E6%97%A5) よりメモ 表題のとおり調査までの議題となるため完了とする。プルリクエスト（ #6099 ）も併せてクローズする（ブランチは残す）。 また実装については #6103 や #6102 にも関わるため実現方法について慎重に検討する必要がある。 なお #6099 は Gem を使用しておらず（search が実装されていなかったため） Web API とのやりとりは `app/models/discord_member.rb` を経由して `lib/discord/resource.rb` が行っている。 加えて #6099 は幅広な調査をしていないため https://discord.js.org/ などの実現方法が Web...

@komagata @machida おはようございます～ 1点質問があります。 メール送信時エラー内容は、ログに出力する必要はありますか？ というのも外部API（GitHubログイン）のエラーを拾っている例では警告レベルのログを出力しているため、監視などで使用しているのではと？気になったためです。 https://github.com/fjordllc/bootcamp/blob/9b48cc611a627be61ae9d05f466695bfe518416b/app/controllers/user_sessions_controller.rb#L57-L58 また、ログ出力が必要であれば上記のコードにならって次の内容を警告レベルのログとして出力できればと考えています。 `[Postmark] 受信者由来のエラーのためメールを送信できませんでした。：` よろしくおねがいします🙏