+const char *
+get_eta (int *bcd)
+{
+ /* Translation note: "ETA" is English-centric, but this must
+ be short, ideally 3 chars. Abbreviate if necessary. */
+ static const char eta_str[] = N_(" eta %s");
+ static const char *eta_trans;
+ static int bytes_cols_diff;
+ if (eta_trans == NULL)
+ {
+ int nbytes;
+ int ncols;
+
+#if USE_NLS_PROGRESS_BAR
+ eta_trans = _(eta_str);
+#else
+ eta_trans = eta_str;
+#endif
+
+ /* Determine the number of bytes used in the translated string,
+ * versus the number of columns used. This is to figure out how
+ * many spaces to add at the end to pad to the full line width.
+ *
+ * We'll store the difference between the number of bytes and
+ * number of columns, so that removing this from the string length
+ * will reveal the total number of columns in the progress bar. */
+ nbytes = strlen (eta_trans);
+ ncols = count_cols (eta_trans);
+ bytes_cols_diff = nbytes - ncols;
+ }
+
+ if (bcd != NULL)
+ *bcd = bytes_cols_diff;
+
+ return eta_trans;
+}
+
+#define APPEND_LITERAL(s) do { \
+ memcpy (p, s, sizeof (s) - 1); \
+ p += sizeof (s) - 1; \
+} while (0)
+
+/* Use move_to_end (s) to get S to point the end of the string (the
+ terminating \0). This is faster than s+=strlen(s), but some people
+ are confused when they see strchr (s, '\0') in the code. */
+#define move_to_end(s) s = strchr (s, '\0');
+
+#ifndef MAX
+# define MAX(a, b) ((a) >= (b) ? (a) : (b))
+#endif
+
+static void
+create_image (struct bar_progress *bp, double dl_total_time, bool done)
+{
+ char *p = bp->buffer;
+ wgint size = bp->initial_length + bp->count;
+
+ const char *size_grouped = with_thousand_seps (size);
+ int size_grouped_len = count_cols (size_grouped);
+ /* Difference between num cols and num bytes: */
+ int size_grouped_diff = strlen (size_grouped) - size_grouped_len;
+ int size_grouped_pad; /* Used to pad the field width for size_grouped. */
+
+ struct bar_progress_hist *hist = &bp->hist;
+
+ /* The progress bar should look like this:
+ xx% [=======> ] nn,nnn 12.34K/s eta 36m 51s
+
+ Calculate the geometry. The idea is to assign as much room as
+ possible to the progress bar. The other idea is to never let
+ things "jitter", i.e. pad elements that vary in size so that
+ their variance does not affect the placement of other elements.
+ It would be especially bad for the progress bar to be resized
+ randomly.
+
+ "xx% " or "100%" - percentage - 4 chars
+ "[]" - progress bar decorations - 2 chars
+ " nnn,nnn,nnn" - downloaded bytes - 12 chars or very rarely more
+ " 12.5K/s" - download rate - 8 chars
+ " eta 36m 51s" - ETA - 14 chars
+
+ "=====>..." - progress bar - the rest