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

Enable The Renderer to Handle 4+ texts #14

Open
Shaun-Regenbaum opened this issue Jan 29, 2021 · 5 comments
Open

Enable The Renderer to Handle 4+ texts #14

Shaun-Regenbaum opened this issue Jan 29, 2021 · 5 comments
Assignees
Labels
enhancement New feature or request question Further information is requested

Comments

@Shaun-Regenbaum
Copy link
Member

As of right now the renderer can reliably handle 1 (?), 2, or 3 texts, no matter their size. Yet, there may be people who want to be able to wrap together 4, 5, or more texts.

@Shaun-Regenbaum
Copy link
Member Author

I think it's a good problem to solve, yet we first need to come up with some sketches as to what that would look like.

  1. The first constraint is that we want a general solution that can scale to any amount of texts. So whichever design we choose, it needs to look good no matter how many inputs we throw at it.
  2. The second constraint is that is needs to something unique that isn't already possible without the usage of spacers (otherwise why would you want to use the package?).
  3. Finally, we need to decide if the behaviour of the first three texts should be changed when you introduce a fourth. Meaning, should what type of expectations do users have when inputting 4+ inputs vs. 3 or less.

@Shaun-Regenbaum Shaun-Regenbaum self-assigned this Jan 29, 2021
@Shaun-Regenbaum Shaun-Regenbaum added enhancement New feature or request question Further information is requested labels Jan 29, 2021
@Jutanium
Copy link
Member

Agree with these questions. We could start with our library and extend it to more texts, but when we move away from duplicating the Vilna, we lose the guarantee that our formatting is useful. Alternatively, we could start with a layout that we are more confident is useful, but then we must reevaluate whether our library is the best tool for the job.

@Shaun-Regenbaum
Copy link
Member Author

Another option is to create another library that is not just for the vilna, then we could focus on what looks best for wrapping texts.

@Jutanium
Copy link
Member

Jutanium commented Jan 31, 2021

@Shaun-Regenbaum I think that's the best approach; i.e. have a separate API designed for Mikraot Gedolot style layouts.
This way we create our library structure using composition: a Mikraot Gedolot layout consists of a number of texts (along with configuration options), but one or more of those texts can be a daf-like.

Examples of a daf-like object inside a Mikraot Gedolot-style layout include Mishnah Berurah with Be'ur Halacha (in my version at least), Siftei Chachamim with Rashi, and Onkelos with Psukim. But this doesn't happen the other way around, so it'd make sense to have the Mikraot Gedolot library be (optionally) composed of daf-renderers.

@Shaun-Regenbaum
Copy link
Member Author

Sounds, good so after I implement tests, Ill close this issue and open a new library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants