GithubHelp home page GithubHelp logo

tlingit-verb-prefixes's People

Contributors

jcrippen avatar

Watchers

 avatar

tlingit-verb-prefixes's Issues

Create macros for repeating text elements

The current source repeats a lot of labels like the header content and table captions. This repetition is error prone. It would not be very hard to replace constantly repeated things like \multicolumn{8}{c}{Classifier prefixes} or first person singular subject /{χ-}/ with TeX macros.

The usual problems with macros apply (moving arguments, eating following spaces). There are also some slight differences in formatting, such as Asp.\rlap{ +} versus Asp.\rlap{+} in tables where horizontal space is a problem. These would need to be either regularized or special cased with some macro magic.

Add tooltips to surface form cells

It might be possible for a PDF to include tooltips on arbitrary non-hyperlink text. If this can be done then we could add tooltips to the surface form entries in each cell. The tooltip could contain the complete underlying prefix string that corresponds to the surface form. For example, table 85 “N-conjugation n- with irrealis u- and modal g̱-, first person singular subject x̱-” has a cell containing oonḵwadzi. This corresponds to the prefix string a-u-n-g̱-x̱-d-s-i-, from the horizontal a-u-n-g̱-x̱- and the vertical d-s-i-. If a reader using an app like Acrobat or macOS Preview hovers the mouse over the form they would see a popup tooltip containing the prefix string. Since this information would be encoded in the LaTeX source it would also be programmatically extractable and hence would simplify developing an automated mapping between prefix strings and surface forms.

Consider removing ‘Prefixes’ column

The ‘Prefixes’ column currently duplicates the information in the ‘Disjunct’ and ‘Conjunct’ = ‘Asp.’ + ’Subj.’ columns. It is useful in that it gives the prefix string as a single concise unit, but it takes up a lot of horizontal space. This isn’t a problem for most tables, but some of them – especially the u- + g̱- + g̱- tables – are near the limit of horizontal space on 8½″ × 11″ paper. Shrinking the font size in these tables would make things significantly harder to read given all the colouring. If the ‘Prefixes’ column is removed then there is a lot of additional horizontal space freed up for loosening the inter-column spacing in these worst-case tables.

If the ‘Prefixes’ column is removed, it could be useful to swap the order of contents in the ‘Disjunct’ column. Currently this is ‹form› followed by ‹description›, e.g. “x̱ʼe- ‘mouth’”. If the order was switched to e.g. “‘mouth’ x̱ʼe-” then this would put the prefix’s form immediately before the prefixes in the ‘Asp.’ column. This would make it easier to read the prefixes as a linear string.

If the ‘Disjunct’ column’s internal content order is swapped then it should probably be switched from left-aligned to right-aligned. The left edge of the tables would look ragged, but the distance between the prefix form and the content of the ‘Asp.’ column would always be the same which would make it easier to read the prefixes as a linear string.

Make IPA/orthography tables optional

Right now every table comes in two flavours: orthography and IPA. This literally doubles the size of the document. Language learners are probably less interested in the IPA representations and so could benefit from a document with just orthography tables. Likewise, phonologists may be less interested in the orthography representations and could benefit from a document with just IPA tables.

Explore the various LaTeX tools for conditional compilation. We would want a flag that turns on one or the other or both. Some problems:

  • Currently each page contains a single pair of tables. A single table per page wastes a lot of space, but there is an uneven number of tables per subsection: |{1SG, 1PL, 2SG, 2PL, 4H}| = 5.
  • A few tables are very large so that pairs are wrapped in a single {table} environment to keep them on the same page rather than separate {table} environments for each table.

Eliminate more ungrammatical combinations

There are several combinations of prefixes that are probably ungrammatical. One particular issue is the any combination of g̱- modality with i- stative without irrealis u-. All the questioned forms need to be reviewed to verify whether they are grammatically possible or not, and those that are not need to be starred with ‘⁎’.

For comparison, see the tables with fourth person human du- for impossible combinations.

Reformat LaTeX source of tables for better parsing and diffing

The LaTeX source code currently represents each row of a table as a single row of text. This makes it easy to read the source, but it actually complicates some automatic tooling. Even if only a single character is changed in one cell, diff considers the entire row to be different. Since the rows are very long this makes interpreting diffs – and thus git output – very hard. It also makes the data harder to parse since a program has to know quite a bit about LaTeX table syntax to pick apart the individual cells in each row.

An alternative format is to put each cell on its own line in the LaTeX source. A line like

cell 0 & cell 1 & cell 2\\

would instead be something like

cell 0
      & cell 1
              & cell 2\\

So that each cell is on a separate line. A change made to a single cell would be seen in a diff by the change of a single line. Parsing a row would be reading each line up to one ending with \\ and then filtering the LaTeX cruft like &. Since each cell is on its own line, the count of lines in a block would track the number of cells in a row and thus make indexing simpler.

Better colour planning

Currently the prefix colours are sort of arbitrary. Before we get locked in to a particular pattern, it would be useful to figure out some ideal sets of colours to use.

Issues to consider:

  • background colours: Currently the assumption is a white background. But what about e.g. a black background, or even a Solarized (https://ethanschoonover.com/solarized/) dark or light background?
  • print versus screen: The current colours are RGB, designed to work on screen. Print colours are generally CMYK, with spot colours also available. Good RGB screen colours may look like crap in CMYK print, and even good CMYK colours might look like crap when blended by a cheap printer.
  • adjacency and contrast: Some colours are hard to distinguish when adjacent. We should try to ensure that colours are maximally contrastive for adjacent characters in all the possible combinations.
  • relative contrast: The current colours have been eyeballed to not contrast too much against each other in terms of their perceived luminance, but this is all guesswork. It would be very useful to look at some perceived luminance models to more reliably select various colours in opposition to each other.

Account for w- irrealis outside of prospective

The w- irrealis prefix is found outside of prospectives in lexically specified (mental state, conative activity, resemblance state, pejorative) and derivationally specified (comparative dimension state, indirect motion, pretend activity, extraordinary state) contexts. Some of these may be u- rather than w- in which case they are already covered. The remaining ones need to be integrated into the document.

One option is to put them in the existing irrealis subsections. They probably don’t occur with the g̱- modal so they would only need to be listed in the irrealis subsections and not in the irrealis+modal subsections. This would require either more rows in the existing tables or new tables.

Another option is to add a separate subsection for them. This would complicate the existing structure of subsections, but it would help clarify their relative difference from the u- irrealis forms.

Some outstanding questions include:

  • Are the w- surface forms always distinct from the u- surface forms or is there overlap? (Dunno.)
  • Is it possible for w- and u- to cooccur? (Probably not.)
  • Are there any alternations between w- and u-? (E.g. negation.)
  • Are there any conjugation prefixes that do not occur with w-? (Probably not.)

Create tables for specific grammatical contexts

Currently the tables are organized by simple combinatoric possibility without regard to meaning. This is useful for phonological analysis but it’s less straightforward for grammatical analysis. We need to figure out how the data can be reorganized to reflect specific grammatical contexts, e.g. the set of all hortatives or the set of all imperatives. This is already in place for the prospective aspect. The perfective aspect tables conflate true perfective (wu- and u-) with ∅-conjugation habituals that have the u- perfective prefix.

Negation (and prohibitive/optative) would be an additional dimension to add to some – but not all, e.g. imperative – of the grammatical context prefix charts. In some cases there is no surface effect – e.g. prospective – so even though negation can happen there would be no difference between affirmative and negative tables. But in others – e.g. perfectives – there is at least i- suppression even if irrealis u- is not discernable. There may also be switching between lexical/derived irrealis w- in affirmatives and syntactic irrealis u- in negatives. So phase II of the grammatical table project could be negation tables.

One early decision is whether these grammatical tables should be in their own document or included as a second part to the existing document. The advantages and disadvantages of both approaches need to be listed and considered.

Flag tables that are identical to other tables

There are several tables that are identical to other tables. Most if not all of these are cases where the irrealis u- does not appear in surface forms, e.g. any combination of u- and one of the subjects {tu- 1PL, i- 2SG, yi- 2PL, du- 4H}. Right now there is no indication that these tables are identical to others apart from mentions in the subsection introductions. We need some sort of sign on each page, perhaps a marginpar note like “(= 149)” that contains a table number with a hyperref link.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.